Re: [sigrok-devel] FPGA LA code status, and plans

[<jo...@ai...>]

Hi Iztok,

It's great to hear all your progress.

Here's some random responses.

>> Also somebody could look into the PIC code and the USB code to start 
>> thinking about generalizing those APIs too.

I think there there needs to be some distributed register interface 
implementation for this. There would be some internal asynchronous 
control bus. Then this could be exposed to the outside world via I2C, 
SPI, UART etc.

>> This is what I have done till now:
>> - recoded module port lists into the less redundant Verilog 2001 
>> style
>> - moved almost all device specific code (clocking, IO) to the top 
>> level file
>> - rewrote memories into generic code, which compiles on all tools (I 
>> plan to properly test this)
>> - replaced blocking assignment operators (used for combinatorial 
>> logic) with non-blocking ones for all FlipFlops
>> - partially changed the coding style where the combinatorial logic 
>> is coded in a sequential language style, not appropriate for RTL
>> - fixed a few instances of the reset signal being 
>> used conspiratorially  more remain in the trigger code, this cause non 
>> optimal code, Synplify will complain about it
>> - changes the naming scheme of data streaming module ports, to more 
>> closely resemble the standard AXI4-Stream [2] protocol, which is 
>> supported by Xilinx [3] and Altera SoC tools
>> - updated the bench code to use some SystemVerilog, I use Icarus 
>> Verilog GIT for simulations
>> - generalized some code have a parameterized data width, currently 
>> it was fixed to 32bits

Wow lots of good stuff. It sounds like you've really made some great 
headway.

I've been working on a separate approach, building from the ground up. 
I've been working on a skeleton project structure for the project, based 
on the common ideas in the popular opencores projects such as minsoc, 
openrisc etc.

These projects have a variety of different approaches to supporting the 
different tools. I've been trying to put something tidy and solid 
together. I want it to be done right - cleanly ordered makefiles, tidy 
source formatting, proper abstraction of alternative tools, no 
crappy/hacky/ugly/dead/untidy/badly formatted code lying around, 
standard/common project structure - doing the job right.

What's your opinion on this? but it seems to me the demon core project 
is far from this state. If we keep the demon core source, I think it 
might be better to import it into a clean skeleton tree.

However, this is my first FPGA project, so my progress has been rather 
slow. It takes time because I have to go search round for enough good 
examples of to find the right thing to do. You are by far the expert 
here, and probably deal with this problem all the time.

I've got so far as having working simulation, and sythesis for xilinx. 
I havn't published this yet, but I might get time to do so tomorrow, but 
also it's not very big or amazing, so maybe you'd prefer to do it 
yourself.

>> After all this changes the FPGA should still be compatible with the 
>> original code.
>>
>> Here are the remaining tasks I have to go through, before I can 
>> start changing the functionality:
>> 1. write module level (sync, sample, trigger, align, rle, memory, 
>> SPI, ...) tests which actually report success/failure of the test, 
>> currently a developer knowing what to expect must look into the waves 
>> and logs
>> 2. write top level tests with success/failure reports
>> 3. fix remaining portability issues, mostly handling of reset and 
>> DDR clocks (should be compatible with  most FPGA device families from 
>> Xilinx, Altera, Lattice)
>> 4. continue with the parameterization of the code, module level 
>> should be tested with different parameter settings
>> 5. just to catch more warnings compile the code using other 
>> synthesis tools (Synplify, Vivado, Quartus)
>>
>> With the next steps backwards compatibility will probably be lost:
>> 1. generalize the memory interface, better separation between the 
>> write and the read side is needed, all data transfers should be 
>> measured exclusively in bytes, this will enable the use of plugable 
>> memory controllers accessing fast and large external memories

Can we define a common interface for this?

>> 3. If I understood it correctly the order in which data is read out 
>> is the opposite of what would be expected, I do not think it does make 
>> sense to keep this for backwards compatibility anymore, since we 
>> control the host software

Sounds weird.

>> 4. some generalizations are needed for a plugable host interface to 
>> support other boards (UART, SPI, FX2 compatible FIFO, I2C, JTAG), also 
>> the host can be inside the FPGA on devices with integrated ARM CPU and 
>> memory controllers (AMBA AXI4 for Cyclone V [4] and Zynq-7000 [5])

I have a Papillio Pro lashed up to an FX2 board with some strip-board. 
I was interesting in the possibility of using FPGALink library and 
firmware.

All these tasks you list sounds fine to me. My only comment is I think 
we need to coordinate better. I didn't know you were working on any of 
this, or you what I was working on. I recommend you come to IRC rather 
than mailing list, especially if you can get a bip server. Currently 
most decisions get made there.

I think we should now try and set up an official repository and get 
some foundation stones in place. How do you want to work this? I don't 
mind sorting it out, though I think you would do a better/quicker job. 
We need to resolve the question of whether to start with the demon core, 
or start with a clean skeleton structure. Then we need to pick an 
initial project name (doesn't matter what it is much, we can give it a 
better one later), then setup repos on sigrok.org.

I'm quite happy to do as much or as little of this stuff. I just want 
to avoid any duplication of effort. Would you be happy to lead this 
project (for the time being)? or is this just a side-project for you?

Joel