Help coding a bigger project

I?m wondering what sort of approach I should have in coding a bigger-than-one-entity-system.

The system is going to use an FPGA to get sample data from two different kinds of AD-converters (6 + 3 A/D-converters in total). Two different LP-filters to filter the signals. An SPI-interface to all send all the data from the FPGA to the next system.

Should I have a single state machine controlling all the different entities? Or should I have some form of signal between the different blocks that determines the dataflow?

Reply to
Bubba
Loading thread data ...

Hello,

The approach is deppending on your application, FPGA resources, maximum throughput.

One alternative might be runing everything at one clock (some high-speed clock), do one state machine which takes care of every entity one-by-one, while reading simultaneously from all the entities and buffering the data.

Vladislav

Reply to
Vladislav Muravin

Break up entities based on reuse, complexity or testbench. Start with a two-level top design entity for each FPGA containing only 1.instances for reused/purchased modules

2.components for the unwritten design entities and 3.signals as needed for local interconnect.

No. In a two-level design, each process has access to the top port pins via the instance port map. Each process also has architecture signals and local variables in scope. If this seems constraining, the entity/process may have to cover more outputs.

The cleanest partition has each entity drive it's own set of output pins via the port map.

If each module has cpu registers, a small signal bus is probably indicated to minimize the signal wiring.

For deeply pipelined designs, you may need to break this up with some entities connected in series via architecture signals.

-- Mike Treseler.

Reply to
Mike Treseler

One way to think about it.. is to try and imagine the design.. if you can't imagine it all then it shouldn't be one module. if you think logically about what modules work with what.. you can usually imagine a simple interface between two parts and the timings can be simple for this. That's where you break modules. The interface can then be fairly logical and simple.

Simon

data

entities?

Reply to
Simon Peacock

Thank you all.

I would like to know I there are any good books about building complex systems with signals between them. The usual beginner VHDL books do not go to deep on these things. :-/

"Simon Peacock" skrev i meddelandet news: snipped-for-privacy@news2.actrix.gen.nz...

can't

fairly

Reply to
Bubba

Consider learning your vhdl simulator inside and out first. Running a top level simulation can quickly answer questions that are difficult to even put into words.

-- Mike Treseler

Reply to
Mike Treseler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.