Virtual channel router verilog or vhdl code

I am designing a router with vitual channels.....
I need help in what way I can design virtual channel buffer

What exactly is the problem?

TrickyDicky said:

What exactly is the problem?

Click to expand...

well.....
I wanted to create virtual channels. Packet will be buffered in one of the four fifo (i.e. 4 virtual channel).
Like virtual channel router.

Shall I instaniate FIFO using generate or instantiateFIFO three times with different read and write pointer

Use a generate and make an array for the read/write data and buses for the single bit signals. Use the loop index to assign the correct bit of the single bits and the correct array word for each data.

could you plz help with some pseudi code or verilog code....

Maybe you should work on learning how to use a search engine.

Try "Verilog generate example" as the search terms. Or better yet find an online tutorial for Verilog as generate is a typical tutorial topic.

can't i use tasks for reading and writing in code....
will it get synthesized?

Tasks are not synthesizable. I think they might be synthesizable if coded as functions. If they are then use a function, therefore I've never done it.

You need to invest some time into reading a tutorial and/or a Verilog book.

@ads-ee, You can synthesiize some tasks. They are incredibly useful for some things. However, they can't have waits our anything that can't normally be in a process. They can remove repetitive blocks of copy/paste code.

@ashish, perhaps you should post pseudocode for your problem. It isn't clear how you want to use tasks to solve this problem. They can be used optionally.

vGoodtimes said:

@ads-ee, You can synthesiize some tasks. They are incredibly useful for some things. However, they can't have waits our anything that can't normally be in a process. They can remove repetitive blocks of copy/paste code.

Click to expand...

Yeah which means they end up more or less similar to functions, which I would use instead. Tasks really only make sense for simulation testbench code. And repetitive blocks of code I use generate and for loops to replicate the code.

Still seems using a synthesizable task just makes the code less portable (I've seen some synthesis tools choke on such coding) and more likely to be a problem with others reviewing your code. Basically wasting everyone's time by having to justify why you didn't use something more standard in your synthesizable code.

As it's probably very apparent, I'm all for writing code that is 100% oriented on maintenance and not displaying how clever you can be. Probably due to being brought onto projects after others have failed and getting them to production level. Most of the the time the failure wasn't that the designer didn't understand the problem, but the fact that they have coded things in such a poor way that the tools can't optimize the design, e.g. huge combinational circuits between FFs, FSMs that have latches, simulation synthesis mismatches due to bad coding style. Along with the inevitable ugly coding formatting that makes the code nearly unreadable (i.e. can't tell where if and else if end at a glance due to lack of vertical alignment). That and people coding with CamelCase really annoys me, since they are usually the ones that make all their signal names like this CmtZmpIntrCBS, CmtXmpInrCBS, CmpZxqIntrCBT, etc. real easy to tell whats what a a glance. :thumbsdown:

ads-ee said:

Yeah which means they end up more or less similar to functions, which I would use instead. Tasks really only make sense for simulation testbench code. And repetitive blocks of code I use generate and for loops to replicate the code.

Click to expand...

Tasks are useful as impure functions that don't have a single output. I forget if you can just call a function in VHDL without using the output. VHDL doesn't do that good of a job with procedures, which does limit the usage. System Verilog has interfaces, which is a step forward. Even when they have benefits, I doubt they will be used due to the stigma of being "simulation-only" or "software-like-design".

Still seems using a synthesizable task just makes the code less portable (I've seen some synthesis tools choke on such coding) and more likely to be a problem with others reviewing your code. Basically wasting everyone's time by having to justify why you didn't use something more standard in your synthesizable code.

Click to expand...

As long as you only use synthesizable constructs, it shouldn't be an issue. It really should take longer to review code without procedures as you need to ensure related signals are always assigned consistently and that any duplicated conditional logic if duplicated correctly.

As it's probably very apparent, I'm all for writing code that is 100% oriented on maintenance and not displaying how clever you can be.

Click to expand...

That was one of the reasons I looked into procedures. There were too many times where I had seen a set of related signals that were assigned inconsistently. This is particularly true when designs are updated. The failure modes were almost always difficult to sim corner cases. It is easy to be unintentionally clever, or even intentionally too clever, even with the basic constructs.

Probably due to being brought onto projects after others have failed and getting them to production level. Most of the the time the failure wasn't that the designer didn't understand the problem, but the fact that they have coded things in such a poor way that the tools can't optimize the design, e.g. huge combinational circuits between FFs, FSMs that have latches, simulation synthesis mismatches due to bad coding style. Along with the inevitable ugly coding formatting that makes the code nearly unreadable (i.e. can't tell where if and else if end at a glance due to lack of vertical alignment). That and people coding with CamelCase really annoys me, since they are usually the ones that make all their signal names like this CmtZmpIntrCBS, CmtXmpInrCBS, CmpZxqIntrCBT, etc. real easy to tell whats what a a glance. :thumbsdown:

Click to expand...

I had the opposite experience when I did VHDL. Most people either didn't understand the problem, didn't understand their implementation choices, ran into some problem and chose a lazy solution, run into a problem and tried to sim their way out of it, or solved a problem that was more interesting than the one they actually had.

Large combinatorial circuits are easy to create from even short blocks of code -- it doesn't take anything fancy. Likewise, I found many developers over design things without justification, often adding "free" register stages without any concept of keeping track of the signals in the pipeline.

@vGoodtimes

I have three lanes of fifo.
if(vcid==2'b00)
data should be written in first fifo
else if(vcid==2'b01)
data_should be written in fifo 2
like this for vcid 3