applet.program.ecp5_sram: Initial ecp5 SRAM applet #191

gregdavill · 2020-04-24T14:39:05Z

I've started working on an applet for the ecp5.

Right now it supports the bare minimum: reading IDCODE, STATUS register and can download a bitstream.

The ECP5 expects the bit stream data to be sent MSB first, which is how the SPI flash is operating, but reverse to JTAG. So we need to reverse every byte before we send it out, I have a very crude implementation of this right now.

electroniceel · 2020-04-24T15:03:16Z

I see that you import bitarray, but don't see that it is used at all. Probably copied from somewhere else?

bitarray has some problems so the plan is to deprecate it. So I would prefer if there were no new users of bitarray added to Glasgow.

I didn't do a thorough review of the rest as I don't have enough experience with the ECP5 and JTAG.

whitequark

Thanks for the PR! I hope this review shows what the applet is missing before it can be on the same footing as other similar applets upstream. If some of my references to *.xc9500xl are too opaque I can elaborate on them, but I feel like just pointing to existing code might be easier.

software/glasgow/applet/program/ecp5_sram/__init__.py

gregdavill · 2020-04-25T00:52:16Z

Yep, bitarray is not needed. I was poking around with it to try to handle the bit reversal. I'll remove the import

Thanks for the comments! I'll work through them now.

Speed on the bit reversal isn't a huge impact. A bigger factor seems to be only calling shift_tdi with 8 bits at a time.

Here is a quick benchmark (552K bitstream, 6MHz TCK) for 2 bit-reversal methods.

Control ( _reverse() ): 14.2s
_lookup_table():        13.7s

Calling shift_tdi with 64bytes. 512 bits
_reverse():      4.7s
_lookup_table(): 4.0s

gregdavill · 2020-10-11T06:08:20Z

This PR has been sitting on my local branch for awhile now, would be useful to get it merged.

Because it's been so long, I've rebased the changes, and squashed my working commits.

whitequark · 2020-10-11T06:12:26Z

Sorry for the delay, I had my hands full. I'll take a look soon!

gregdavill · 2021-05-01T12:03:08Z

Anything I can do to help this along?

whitequark · 2023-10-28T13:17:11Z

@gregdavill Apologies for the huge delay--I'm currently working on updating this applet to the latest coding standards and working on merging it. I do have a few questions about the way you wrote it.

whitequark · 2023-10-28T13:17:50Z

software/glasgow/applet/program/ecp5_sram/__init__.py

+
+        # Send entire bitstream data into DR,
+        # Bytes are expected MSB by the ECP5, so need to be reversed
+        # Slit bitstream up into chunks just for improving JTAG throughput


Does this really improve JTAG throughput? Is it because the byte reversal operation is so slow it pays off to run it in parallel with actual JTAG upload?

So the part that's slow isn't byte reversal but converting a gigantic bitstream back and forth from bytes to bits to bytes again (in the JTAG code). This is ... awkward.

whitequark · 2023-10-28T13:35:06Z

software/glasgow/applet/program/ecp5_sram/__init__.py

+
+
+        # Check status
+        # Note ECP5 will not release until STATUS is read


ECP5 will not release what? The DONE pin?

I can double check this, I seem to recall that the device remained in a configuration state, as opposed to a running state.

whitequark · 2023-10-28T13:36:50Z

software/glasgow/arch/lattice/ecp5.py

@@ -0,0 +1,84 @@
+from ...support.bits import *


Do you remember which document this data is taken from? (It needs to go into our documentation archive.)

Namely, the LSC status register is described in FPGA-TN-02039, but I cannot find a document which lists IR values.

Yes, in FPGA-TN-02039 ECP5 and ECP5-5G sysCONFIG Usage Guide the commands listed under 6.5 Slave SPI Command Table. These values are used by the SPI access to sysCONFIG. They are the same as IR values used via JTAG.

The variable used to be called `args.bitstream`, which clashed with FPGA programming related applets; program-ice40-sram and the upcoming program-ecp5-sram. Rename it to `args.prebuilt_at` (as the option), reducing the likelihood of name clashes. Eventually we should have proper namespacing here, but that's a lot more work than I can do now.

whitequark · 2023-10-28T15:30:46Z

An issue I found while testing this applet is that it does not (as written) assert PROGRAMN at the beginning of configuration, so if e.g. there was already a bitstream, or if a bitstream load finished with an error, this state is preserved even if another bitstream load is performed.

software/glasgow/applet/program/ecp5_sram/__init__.py

whitequark · 2023-10-28T16:30:01Z

@gregdavill I've updated the applet to follow all of our standards and guidelines; it is almost ready to be merged! There are only a few items left.

Functionality:

The applet does not assert PROGRAMN at the beginning of configuration. This is probably done through some register, but without documentation (per items below) it's hard to figure out which.

Documentation:

Where did you obtain the encodings for IR_* instructions in glasgow.arch.lattice.ecp5?
Where did you obtain the programming algorithm for bitstream burst load?
Are the 10 cycles in Run-Test/Idle specified by some document (which?) or is this just a guess?

whitequark · 2024-03-06T00:41:34Z

@gregdavill Friendly ping--I'd like to merge this! I've been explicitly allocating resources for Glasgow maintenance recently so things should go faster.

gregdavill · 2024-03-06T12:13:50Z

Thanks for the ping. I had totally not seen the work you put into this in October. Thanks.
I've not taken a look at this code for a long while, thought I'd reply with answers now.
I'll get my glasgow set up again and try out the changes soon.

Functionality:

The applet does not assert PROGRAMN at the beginning of configuration. This is probably done through some register, but without documentation (per items below) it's hard to figure out which.

I can take a look into this. Not that the sysConfig block exposes the same (or a subset?) register set via both SPI and JTAG. I have found it useful to use to the "SPI" commands/timing and registers even when using JTAG. The docs don't appear to make this obvious.

The programming flow listed in 6.10 appears to claim that toggling PROGRAMN and clocking in the REFRESH command are equivalent, I've not checked this claim.

Documentation:

Where did you obtain the encodings for IR_* instructions in glasgow.arch.lattice.ecp5?

I've taken the SPI commands, as listed FPGA-TN-02039 section 6.5

Where did you obtain the programming algorithm for bitstream burst load?

IIRC Initially nextpnr-ecp5 ecppack, as it has an option to export a programming SVF,. However the flow is essentially the same as described in FPGA-TN-02039 section 6.10.

Are the 10 cycles in Run-Test/Idle specified by some document (which?) or is this just a guess?

I think 10 cycles was a guess that worked, or it was used by the SVF.
But in FPGA-TN-02039 section 6.6: LSC_ENABLE/LSC_DISABLE are classed as type C commands, these list 24 dummy clocks after the opcode, but also state that "command action starts on 3rd dummy clock.".

whitequark · 2024-06-22T13:20:52Z

@gregdavill Hi! Pinging you again on these changes.

For documentation I'd like it to be added to our archive and the header to be updated to list it, the same way it's done in other files.

For the functional difference of 24/10 clocks I'd like that to be added to the applet.

whitequark requested changes Apr 24, 2020

View reviewed changes

gregdavill force-pushed the ecp5_sram branch from 6dec52e to 7184483 Compare April 25, 2020 03:13

gregdavill mentioned this pull request Apr 25, 2020

RFC: applet.program.ecp5_flash #192

Open

gregdavill force-pushed the ecp5_sram branch from b85a099 to 96edd46 Compare October 11, 2020 06:04

Base automatically changed from master to main February 27, 2021 09:59

gregdavill changed the title ~~RFC: applet.program.ecp5_sram: initial ecp5 applet~~ applet.program.ecp5_sram: Initial ecp5 SRAM applet May 1, 2021

whitequark reviewed Oct 28, 2023

View reviewed changes

software/glasgow/applet/program/ecp5_sram/__init__.py Outdated Show resolved Hide resolved

applet.program.ecp5_sram: new applet. (WIP)

6073637

whitequark force-pushed the ecp5_sram branch from 96edd46 to 6073637 Compare October 28, 2023 16:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

applet.program.ecp5_sram: Initial ecp5 SRAM applet #191

applet.program.ecp5_sram: Initial ecp5 SRAM applet #191

gregdavill commented Apr 24, 2020

electroniceel commented Apr 24, 2020

whitequark left a comment

gregdavill commented Apr 25, 2020

gregdavill commented Oct 11, 2020

whitequark commented Oct 11, 2020

gregdavill commented May 1, 2021

whitequark commented Oct 28, 2023

whitequark Oct 28, 2023

whitequark Oct 28, 2023

whitequark Oct 28, 2023

gregdavill Mar 6, 2024

whitequark Oct 28, 2023

whitequark Oct 28, 2023

gregdavill Mar 6, 2024

whitequark commented Oct 28, 2023 •

edited

Loading

whitequark commented Oct 28, 2023

whitequark commented Mar 6, 2024

gregdavill commented Mar 6, 2024

whitequark commented Jun 22, 2024



		# Check status
		# Note ECP5 will not release until STATUS is read

applet.program.ecp5_sram: Initial ecp5 SRAM applet #191

Are you sure you want to change the base?

applet.program.ecp5_sram: Initial ecp5 SRAM applet #191

Conversation

gregdavill commented Apr 24, 2020

electroniceel commented Apr 24, 2020

whitequark left a comment

Choose a reason for hiding this comment

gregdavill commented Apr 25, 2020

gregdavill commented Oct 11, 2020

whitequark commented Oct 11, 2020

gregdavill commented May 1, 2021

whitequark commented Oct 28, 2023

whitequark Oct 28, 2023

Choose a reason for hiding this comment

whitequark Oct 28, 2023

Choose a reason for hiding this comment

whitequark Oct 28, 2023

Choose a reason for hiding this comment

gregdavill Mar 6, 2024

Choose a reason for hiding this comment

whitequark Oct 28, 2023

Choose a reason for hiding this comment

whitequark Oct 28, 2023

Choose a reason for hiding this comment

gregdavill Mar 6, 2024

Choose a reason for hiding this comment

whitequark commented Oct 28, 2023 • edited Loading

whitequark commented Oct 28, 2023

whitequark commented Mar 6, 2024

gregdavill commented Mar 6, 2024

whitequark commented Jun 22, 2024

whitequark commented Oct 28, 2023 •

edited

Loading