On Mon, Jun 3, 2013 at 5:35 PM, David Koontz <[email protected]> wrote:
> > On 4 Jun 2013, at 6:13 AM, Jon Taylor <[email protected]> wrote: > > Setting stop-delta to 2 billion seems to make the simulation run long > enough to enable me to test my code - the native sockets I'm using to > emulate a bus aren't timing out any more. Later on when Controlix gets more > controls and the execution environment is ready to run bare-metal on a CPU, > I will probably need to compile my own simulation code with -stop-delta > disabled as you describe. > > > I was under the impression from the Controlix blog > Update<http://sourceforge.net/p/controlix/blog/2013/05/update/> you > were planning on eventually getting around this limitation lacking > portability: > > > - All process are now self-clocked to run independently. Each process > is made sensitive to a unique signal which is precessed within the process > itself (usually at the end). While this isn't at core synthesizable (each > process becomes a testbench |->), it shouldn't be much work later on to > precess each process' clock signal off a master clock of some type, thus > solving that problem. I just don't want to have to fiddle with > synchronizing that many signals right now, when I have a lot of general > code I need to get working... at least I don't have to run any more > infinite loops anywhere in the whole codebase to get process to progress in > general, and I am free to write "real" (i.e. orthogonal) VHDL code as I > need to. > > Yes, that is true. A real multithreaded simulator/executor is another one of my goals, to enable multithread-style execution of the controls on a CPU based system. It is possible to get around this with very finely structured control design modularity and a native signal server type of thing, but I am really trying hard to keep as much "VHDL-style" logic throughout the system as possible so as much of the total codebase as possible can be synthesized. > One design goal of Controlix<http://sourceforge.net/p/controlix/wiki/Home/> is > stated as: > > > - Based on the VHDL language for concurrent, verifiable and > sythesizable programming. Run the same systems code in userspace, as an OS > on a CPU-based system, in parallel on an FPGA or even masked into an > integrated circuit! > > > the ability to target hardware implementation through synthesis. > > I used to be an ASIC guy from the 1980's forward. The complexity of the > networking stuff is on the same order as a full featured networking switch > chip these days, and you can imagine likewise requiring exception > processing (a CPU somewhere, dragging down performance). > I actually would prefer to use a separately-threaded back-end for general-purpose I/O and bus management (interrupts, exceptions, mcopy(), mmap(), etc) when running on a CPU-based system. That way I don't have to drag that stuff into a synchronous (polling) execution environment like VHDL, and it can be cleanly separated from the basic I/O code, This should keep down the use of reentrant functions (i.e. callbacks from native code into VHDL code) in the GHDL environment, which I haven't yet made to work.... > > Coming up with targeted 'chip' boundaries might allow you to tackle > conversion to hardware targetable implementation on a case by case basis. > The idea being a pure behavioral model which becomes mixed mode and > eventually capable of becoming hardware. The early conversions teach you > how to do the latter faster and more efficiently. > > Your short term solution sounds like it will only work when simulation > time doesn't advance and it's likely the more you count on synthetic > programming in lieu of hardware simulation the harder it will be to target > hardware later. > Well, right now might be a bit on the early side for worrying much about that issue - I still haven't gotten GHDL to build all the way yet |->. What I have now works OK, warts and all, and it does provide a decoupled-process execution environment which is one of my goals. Jon > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss > >
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
