RTL simulation

[Drake]

Hello go-nuts,

As an academic project to better understand hardware simulation, I
thought about putting together a toy discrete event simulator that
implements a small subset of the SystemVerilog simulator model. After
reading through the Go tutorials, the focus on concurrency seems like
this language might be a good fit.

I'm not very well read on this subject, so I'm looking for materials
as a starting point... also thoughts on how idiomatic Go might be an
excellent language for such a project.

Thanks in advance.

[Kai Backman]

On Wed, Aug 4, 2010 at 5:36 AM, Drake <cjd...@gmail.com> wrote:
> I'm not very well read on this subject, so I'm looking for materials
> as a starting point... also thoughts on how idiomatic Go might be an
> excellent language for such a project.

Are you looking for materials on Go or discrete event simulators?
(I've done both)

Go is probably as good a language as any for writing a DES. Especially
interfaces will make writing the components quite a snap. That said,
if you want to make a concurrent DES that's a hard problem in itself
independent of implementation language.

Kai

[Drake]

On Aug 3, 11:24 pm, Kai Backman <kai.back...@gmail.com> wrote:

> On Wed, Aug 4, 2010 at 5:36 AM, Drake <cjdr...@gmail.com> wrote:
> > I'm not very well read on this subject, so I'm looking for materials
> > as a starting point... also thoughts on how idiomatic Go might be an
> > excellent language for such a project.
>
> Are you looking for materials on Go or discrete event simulators?
> (I've done both)

I think golang.org is quite sufficient for Go documentation. As for
DES, I would definitely value a book recommendation from you. After
looking around a bit, I think I'll just start by copying what "sympy"
does, and see if I can adapt the way they use python "yield"
coroutines to Go's goroutines.

[Karl]

Hi Drake
Most, if not all hardware simulators require HDL(Verilog) to be
compiled to RTL first. so the parallelism/concurrency that is talked
about does not come from the Verilog language. If you stop and think
about how a cpu works, it boils down to control logic, data flow
logic, registers, and the clock. The logic is synchronous so the only
"event" that matters is the clock edge. Therefore, evaluate the
controls and data manipulation and save the results and use those
results to change all the registers at the clock event(exactly what
happens in the computer). The power of go routines is not really
needed for this case.. The HDL's are description languages, not
programming languages, and that is why cpu's are used in embedded
systems when there is need for programmed function in the
application. Go should be fine. just that you may not need all its
power.

[Kai Backman]

On Wed, Aug 4, 2010 at 6:33 PM, Drake <cjd...@gmail.com> wrote:
> I think golang.org is quite sufficient for Go documentation. As for
> DES, I would definitely value a book recommendation from you.

This is a pretty good reference:
http://www.amazon.com/Theory-Modeling-Simulation-Bernard-Zeigler/dp/0127784551

Based on what Karl said I think you might be better off by starting
with a simple discrete time simulation where you just advance every
part of the simulation as you go. I don't know sympy or HDL simulation
very well so I might be totally wrong.

Kai

[Karl]

Since you are focusing on hardware(logic) simulation, here are a
couple of thoughts from an old logic guy: There is control logic, data
flow,
storage(latches, regs, memory) and time events. Events occur in time
sequence
and can be associated with a value that represents time, i,e, the
number of
clock oscillator cycles or a number representing delay time.
Evaluating
control - Boolean expressions - determines what can occur when an
event occurs
and evaluating the data flow expressions determines the new storage
values.

This of course is a subset of general DES.

In synchronous logic there is a capture/launch behavior in the storage
elements, so
saving the values of data in for each element without changing any
element allows
all storage elements to be changed for the launch. Repeat for each
clock cycle.

Asynchronous logic relies on timing the changes such that the din
values are stable
during the setup and hold times. Also there is no separate launch
phase so the
order of changes affects the time it takes to resolve the logic for
the next event. If
the next event can be triggered by any of the current changes, then
there may be a false
trigger during the resolution interval. These are the glitches that
cause most designs
to use clocked capture/launch so there is time for the circuits to
resolve.

Timing driven simulation where each circuit and wire delay is
calculated to determine the
next data in values is much more tedious (Impossible because all
physical properties that
affect timing are unknown) so static timing analysis is used to ensure
that setup and hold times are met.

On Aug 3, 10:36 pm, Drake <cjdr...@gmail.com> wrote: