Hi Joel, On Tue, Apr 30, 2013 at 10:06 AM, Joel Holdsworth <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi Iztok, > > You've really got into this thing! It's awesome.
For me it makes sense to first understand the existing code, I usually do this by editing the code, doing some vectorization, cleanups, ... > > I wanted to discuss with you where we should go from here... > > A lot of people on IRC are suggestion we should start with a fresh > empty repo, and then progressively harvest code from the Demon core, > rather than trying to get it into shape as it is. > > Do you think it's really worth trying to use the Demon core as our > base? Maybe it would be better to start with a folder structure, and > some makefiles and build from there. I do not really care if we start from an empty repo, or if we just rename the existing master into a branch and repopulate the master afresh. The only difference is the download size of the repo. > > I'm guess I'm saying we should agree some plan of where to go from > here. Do we need to do some more design work in the wiki? or can we > start coding immediately. Should we start fresh or hack on the demon > core? Is fpgalafw an acceptable name for the project? - if so when can > Uwe set up project repos. There is no simple reserved name for the "FPGA bitstream" (FPGA configuration, sometimes firmware, sometimes hardware). It is common to have a CPU inside the FPGA, and the code executed by the CPU would be firmware. It is also possible that a LA board would contain both firmware (some CPU, maybe FX2 or PIC) and hardware FPGA bitstreams, so I propose the name "fpgalahw". > > I was going to get started on this myself after the release. But I > don't want to end up duplicating effort with you. I will first try to understand the current FPGA code, this will be my only focus. So if you wish to avoid duplication, avoid the "trunk/Verilog_Core" directory. Was your intention to work on the HDL (RTL and test code)? > > On the subject of folder structure, I've been thinking of something > like this: http://sigrok.org/wiki/Fpgalafw#Project_Folder_Structure > Might need some adjustment though. A common HDL project directory structure looks like this: - rtl (contains synthesizable Verilog code) - tbn ("Test BeNch", usually just "bench", contains non Synthesizable Verilog verification code) - sim (simulation scripts) - syn (FPGA synthesis project, this is present only for top projects, not for components) Each shared Verilog component (memory controller, run length encoder, trigger decoder, host interface (SPI, UART, FX2 FIFO bus, ...), ...) can have this structure. Each board can also have the same structure, since it contains a top level file with the boars specific IO ports, each board also needs some simulation files. The synthesis directory is only needed for the boards. > > Joel > Regards, Iztok Jeras > > On 30/04/13 07:13, Iztok Jeras wrote: >> Hi, >> >> I found other portability issues in the design, they will require >> modifications to most of the code. >> >> 1. reset The design is coded specifically for FPGA, where all >> FlipFlops power up with in the state zero. I am an ASIC developer >> so this bothers me. But the main issue is the reset signal for the >> logic is not connected at all, so there is no way to reset the >> design except power-up. If we would port the design to a board with >> a proper reset signal, and we would wish to use it, the RTL would >> have to be modified, so control logic uses the reset, while the >> data paths usually can work without reset. Currently many control >> signals are initialized to zero in the RTL, this is required for >> the simulation to work properly, but it prevents a proper tesr for >> the reset signal. The solution is to use a macro for the >> initialized value (`define INIT = '0) and for the reset test use an >> undefined value for initialization (`define INIT = 'x). >> >> 2. use of nonblocking assignment (=) for FlipFlops The correct >> assignment operator for FlipFlops is blocking (<=), many modern >> synthesis tools report errors here. I am not sure if this is an >> archaic coding style or it is due to conversion from VHDL, but it >> should be fixed. The problem is, it seems some tests rely it, and >> it will take me some time to understand why. The execution order in >> the simulator depends on the used operator, the unit delays (#1) in >> the combinatorial logic are probably there to force a certain >> execution order, but they should not be necessary. >> >> I also have issues with the coding style for registers, where the >> combinatorial input into the register is coded separately from the >> register itself, and the combinatorial logic is using approaches >> typical for sequential languages. This is very uncommon, but not >> actually a bug. >> >> Regards, Iztok Jeras >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRf3ueAAoJEIsWlGmq62IgLcQH/1x638m+PdUkRQ7CjdkXS1I3 > 8UQYpP/h6wk4nSlxehZ+eiiWwKCxITuIRSzyy+Gm7yWeCg/rPJhWzER2v2ybMHel > KGtcp92woe6jGcfvjmayfEfL4rllMJKqFF4Czn7q4JsFJPhl/S27PB29r0yPilMK > iiMnYgfpUQD567CylF7cbkcISvhiOnmZOxnpDadmjTtee5DVRn96z8ZvFGpQVvbk > gibdl/0XDV7GFmphacUnQltxrTwStHoAqTFnGoqcDdBqhib9iCkUqWrJwXVl5He2 > +WpsyHdCv63jJnUnVJK6ZuGsxj4kEQJJZeTwDuGsSQTPH3TDVyC6vCB4/rV3tww= > =uxh6 > -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
