Bug 698 - ls180 ASIC test tasks
Summary: ls180 ASIC test tasks
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Hardware Layout (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on: 383
Blocks:
  Show dependency treegraph
 
Reported: 2021-09-17 09:26 BST by Luke Kenneth Casson Leighton
Modified: 2021-10-27 20:24 BST (History)
4 users (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2021-09-17 09:26:17 BST
>>  * clock reference for PLL
>>  * Clock multiplier selection for PLL
>>  * reset
>>  * JTAG
>>      o Test outputs directly with boundary scan
>>      o drive internal memory mapped peripherals directly without
>>        needing CPU
>>      o test on-chip memory; load programs into it
>>  * GPIO

equipment needed:

* TODO

links:

* https://lists.libre-soc.org/pipermail/libre-soc-dev/2021-October/003950.html
* https://lists.libre-soc.org/pipermail/libre-soc-dev/2021-September/003729.html
* https://libre-soc.org/180nm_Oct2020/ls180.svg
* https://ftp.libre-soc.org/course_18oct2021/
Comment 1 Luke Kenneth Casson Leighton 2021-10-27 12:26:06 BST
here is the diagram for the pinouts, it was auto-generated
by the pinmux program

     https://libre-soc.org/180nm_Oct2020/ls180.svg

* the IO rail is 3.3v
* the core rail is 1.8v
* P_SYS_PLLCLK (N29) is a *digital* input clock (can be generated by FPGA
  or by signal generator)
* the P_SYS_CLKSEL_0 (N30) and P_SYS_CLKSEL_1 (N31) if set LO
  will route the digital input clock directly to sys_clk

JTAG can be done by openocd using an FT232, configuration setup description
and options are here:

     https://libre-soc.org/HDL_workflow/ECP5_FPGA/

we colour-coded the FT232 pins:

     https://libre-soc.org/HDL_workflow/ft232.png

there is "firmware upload" software written in python that connects
to jtagremote (openocd can be put into "jtagremote" mode):

    https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/debug/firmware_upload.py;hb=HEAD

there is more in that same directory.

and there is openocd commands for running some rudimentary SVF files
and also openocd.cfg for using with FT232 

https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=openocd_ft232.cfg;h=a30c1a40748e1c34faf40ccc7601b3c1eda0fd4d;hb=b55917aafa6bbc9f16e1d97dc095e929c31aa81a

https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=README.txt;h=56adddf762d1ef5673a41e3fca87acd9263c9a34;hb=b55917aafa6bbc9f16e1d97dc095e929c31aa81a
Comment 2 Staf Verhaegen 2021-10-27 17:54:45 BST
I think a block diagram of the SoC and a memory map of the IP blocks would also come handy during testing.
Comment 3 Luke Kenneth Casson Leighton 2021-10-27 20:24:33 BST
(In reply to Staf Verhaegen from comment #2)
> I think a block diagram of the SoC and a memory map of the IP blocks would
> also come handy during testing.

good point.  fortunately, very recently, the IBM India sponsored Educational
Course on OpenPOWER is running, the diagrams are here (and now in comment #0)
https://ftp.libre-soc.org/course_18oct2021/

diagrams 1 and 4 are the most useful.  memory map: basically autogenerated
by litex so needs to be "dug out" of the build process information, beyond
that, the one thing i made sure was that the UART was at the exact same
memory address as Microwatt.

oh, also, the boundary scan order.  manuel i must apologise, there was not
enough time to put it into "pinout sequential order", however hmm now that
i think about it, i can probably get the pinouts svg-generator program to
at least print out the offset and IOType.  or, update the program that
generated the pinouts page

https://libre-soc.org/180nm_Oct2020/ls180/

hmmm although i now realise, those are the die pinouts, not the *package*
pinouts, although there is a programmatic map for them in the autogeneration
of the SVG, i haven't had time to include that in the autogenerated
ls180.mdwn file

the offset and IOType is defined (python source code) here:
https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;h=1f3d424cbd7451c0434e0c71168f5aa0935af860;hb=9c233cbd457dd262e78d5b9c33b3aa4fb82febb7#l163

 163 class IOConn(Record):
 164     lengths = {
 165         IOType.In: 1,
 166         IOType.Out: 1,
 167         IOType.TriOut: 2,
 168         IOType.InTriOut: 3,
           }

yes, really, python to define HDL JTAG Boundary Scan Registers :)

i will dig up the sequence somehow, so that you know if you set JTAG
register X to 0b000100.... it sets a certain (expected) pad.