struggling with general digital design

Hi everyone! I am new to digital design and need some general advice on it.

I have experience with microcontrollers and other chips, but when it comes to designing with FPGAs, I am having difficulty starting moderately complex projects. I am comfortable enough with VHDL that I think I should be able to start solving more advanced problems. VHDL is not the problem.

I think the problem is that I don't know how to design a complex digital system. I tried thinking in software, but it doesn't seem like a good idea, too much time is spent on simple things. The elementary digital design course I took some time ago doesn't seem to help much: knowing basic logic gates/theorems and minimizing equations with K-maps doesn't do me any good.

Currently I am trying to design a system with ADC -> ISSI RAM ->

FFTcore -> ISSI RAM -> DAC.

ADC obtains data, stores it in external SRAM, then FFT core takes this data from RAM and stores its results in another block of RAM. Then the results are output from RAM to DAC.

I need general advice on how to approach the design of this system. Should I start with a block diagram, and try to work out simple blocks of my system?

I already have working code where ADC loads data to FGPA and this data is immediately sent to DAC. I also can read/write from external RAM (as a separate block). But I don't know how to connect the two blocks together. I don't feel like I am spending my time productively at the moment.

Any advice would be highly appreciated. Thanks in advance, Pavel

Reply to
Loading thread data ...

Hi Pavel,

What does ISSI stands for?

Yes, you should start with a block diagram, but the dataflow you mentioned is essentially the one. To help you more we would need to know more about the system:

  1. Does it have it run continiously or in bursts?
  2. Are the ADC and DAC sampling rates the same?
  3. What is the FFT core interface?

You probably will need a simple state machine to control the data flow. It will sit in the idle state waiting for a start condition. As soon as it happens it will go into the fill_input_buffer state, in which it will be incrementing the memory address. Then it will go into the do_fft state, etc. However, this idea of a single sequential state machine might not work if the data flow needs to be continious. In that case you will need to double the buffers and organize the process of their swapping during each cycle: while the ADC fills out one side of the input buffer, the FFT core reads data from another side, and similarly at the output. Obviously, the FFT has be fast enough to process the block before the next block is ready...

Hope this helps a little bit.


Reply to

Hi Telenochek, I am also new to this field. now have only 1 year exp. but still i can tell you that the bock diagrtam level design is the best starting point.

  1. Draw all the necessary blocks.
  2. Conect all those blocks with the signals you think is needed.
  3. Think about the blocks then, find out what is needed in the blocks to satisfy the signal conditions.
  4. If necessary draw the timing digrams.
  5. then start coding the thing. all the best with your design..... sumesh
Reply to

Integrated Silicon Solution, Inc probably. An SRAM manufacturer.

formatting link

Cheers, Jon

Reply to
Jon Beniston

Are there any time restrictions for data getting from the ADC to the DAC ? What about system clock of your FPGA ? Any idea how fast you want your design working?

Try simulating your parts of your FPGA design. VHDL testbenches ...

Rgds Andr=E9

Reply to

There is a good test bench generator called "synapticad". Its ver good. u can draw your timing diagrams in it and can generate verilog or VHDL test benches from that.

Reply to

There is a good test bench generator called "synapticad". Its ver good. u can draw your timing diagrams in it and can generate verilog or VHDL test benches from that. Its available for free trial of 15 days.....

Reply to

ISSI is a chip vendor.


Reply to
Andy Peters

As much as I think that Synapticad's timing diagram tool is pretty neat, I think that test benches generated from timing diagrams are unmaintainable and not very helpful.

A proper test bench will have bus-functional models of the ADC and DAC digital interfaces, and a model of the SRAM, all connected to the device-under-test (the FPGA).

Yes, it takes more work to create these models, but you do it once and you can use them on all of your designs.


Reply to
Andy Peters

I am trying to design with state machines. For example there is a master FSM (finite state machine), which calls slave state-machines along the way, waits for them to end (via slave-busy signals) etc... Unfortunately this approach becomes very messy very quickly.

So, I decided to look at the professional code, such as PicoBlaze soft processor code, and some video application examples on Xilinx website and although there are certainly state machines here and there, it seems that most of the code is kind of .......... architectural. In other words there are many components and control signals.

I understand the breakdown into components when somebody else writes it, and I understand the code, and how everything is connected. The problem arises when I need to come up with all the control signals myself, and make sure the dynamics of the system is working ok.

I think thats a digital design problem, rather than a coding problem. Coding is *relatively* easy when you have a clear design.

Thats why I was wondering how the more experienced folks come up with their designs.

It bursts, the idea is that much high frequencies can be sampled, by simply loading all the data into high speed memory. The FFT will then work on the data in RAM, because its not fast enough to process data in real-time. Once FFT is finished it stores the results in another block of high-speed RAM. The architecture of the FFT core is such that once it unloads the results, it loses them forever. However, if the results are stored in RAM, then you can output them continuously (for example to DAC, for viewing on the scope). And other blocks (to be added eventually) will be able to access the results if they need to. For example a USB link to PC for data processing could use them.

Reply to

Don't try to make your design look like a text book state machine. Make your design look like a VHDL synchronous process with local variables (or signals). Let synthesis worry about the details after your simulation testbench is working.

I agree. Focus on describing your design in terms of vhdl entity inputs and vhdl process variables.

You are designing a simple controller, not a cpu.

You can complete your design in a single entity.

This is what your vhdl simulator is for.

You need to run some simple testbench examples through a vhdl simulator to learn how to *describe* a controller in terms of a synchronous vhdl process.

while not done loop sketch_in_notebook; simulate; edit; end loop;

-- Mike Treseler

Reply to
Mike Treseler

I think you should be able to fit it into a single, relatively simple, state machine.

You should try thinking in terms of hardware. In other words your code should be describing hardware rather than its abstract behaviour. The only exception in my view is a state machine. When I write state machines I usually think in behavioural terms first and then add details later.

Which FPGA are you designing for? If you are using Xilinx, I suggest that you use their Core Generator and generate a simple dual port memory buffer. It will create a VHDL component declaration and an instantiation template. Look at the interface and read the data sheet to understand what each of the signals is for.

If you are still confused, I can probably share some code with you as I do have some similar designs...


Reply to

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.