Hi Joel,


On Sat, May 11, 2013 at 4:06 PM, <joel@airwebreathe.org.uk> wrote:
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.

Could you give me some more details what do you mean by distributed register interface? We probably need generalizations both in software and in hardware.
 

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.

There were vacations for the 1. of May, my wife was not happy with me spending them behind the monitor.
 

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.

We can never do everything right :). But we can make a good compromise between clean code and actually releasing something.
 

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.

From my point of view with the work I have already done, it would make sense to clone my repo from github and then remove everything except the Verilog directory:
$ git clone git@github.com:jeras/butterflylogic.git
$ cd butterflylogic
$ git filter-branch --subdirectory-filter trunk/Verilog_Core/ -- --all
This would keep some history from SVN, and all my changes. My directory structure is not final, but Git can handle file moves
 

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.

Yes, HDL coding does involve some secret receipts. The code which can be properly synthesized is actually a small subset of the Verilog language, many details have to be learned by experience.
 

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.

Please go on and publish your work. I went ahead quickly and I am sure I made a lot of mistakes breaking the functionality. But this is how I tend to learn the functionality of the code. Once I will understand the functionality well I will be able to update the tests environment to actually report test failures, and I will be able to fix my regressions.
 


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?

Here again AXI4 (for CPU busses) is becoming a standard, but for most existing memory controllers older (Wishbone, AHB, ... ) protocols would be used. So I think it does not make sense to standardize to a CPU type bus, instead use the much simpler streaming protocol AXI4-Stream as a standard and write blue logic as needed. Glue logic would be needed in any case, so it makes sense to use the simplest common denominator.
 


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.

I do not know the details, I only read the comment in:
rtl/sram_interface.v
 

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.

 The http://papilio.cc/index.php?n=Papilio.PapilioPro could be used as a test board for FTDI FT2232 host interface (I have to check how exactly is the chip connected to the FPGA), and if you have FX2 connected to it, for the FIFO interface also.
I am going after http://www.altera.com/b/arrow-sockit.html.
 

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 will try to connect to IRC in the next days, at what time the channel is most active. Please also give me a link to existing conversation logs, if available.
 

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.

Regarding the repo, I gave suggestions on how to handle my existing work above. I do not have to think about the name right now, I made some suggestions in the previous discussion.
 

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?

I would actually be happy to lead the FPGA coding for sigrok. I already wrote the 1-Wire Python decoder, but in Verilog I can offer much more. But still I have a full time job, so I will probably spend about 10 hours a week on sigrok FPGA code.

Regards,
Iztok Jeras
 


Joel