Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Bidirectional overhead arrays

Status
Not open for further replies.
S

Saltwater

Member level 3
Joined
Aug 30, 2015
Messages
64
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,867
Hi,

Im having trouble with wrapping my head around some array management in "s" verilog.

The case is as follows I have a module getting variables from an array and putting them back altered, on which the array is read out in other parts of my code.
The bog standard version of getting array tables into registers, gives me an error "multiple assignments" for the node putting the variable into the array, even tho this inferred by logic.
The problem arises I think because of the values being read out in other parts of my code. Making a wire for the output value to the array compiles, but has not taken off yet.

My question is twofold, is there syntax for calling an overhead array in verilog like "module.array[index]" or "module.array[vector][index]"?
also, is this possible to have wires from this array, when another part is setting the value? or do I need to lock the array?


Regards,
 

Re:Error (10028): Can't resolve multiple constant drivers for net "<auto-generated>"

I rebuilt the problem,

the error is:
Error (10028): Can't resolve multiple constant drivers for net "<auto-generated>"
Click to expand...
The array is called twice at the module header, that seems to be the main problem..
Code: 
listfp LFP(
.invararr(valuearray[IDX]), [COLOR="#B22222"] "calling array"[/COLOR]
.vararr(valuearray[IDX])); [COLOR="#B22222"] "new array output"[/COLOR]
Im struggling to find a workaround for this, is there a solution?
 

I seem to have solved it by using a wire to an always block. Code is still wonky tho, cant tell for shure.
 

It seems like your problem has more to do with treating Verilog like a programming language, than describing a hardware logic design.

It looks like you are trying to use the array like a memory array in C than as a block of RAM or a bank of flip-flops.
 

ads-ee said:
It seems like your problem has more to do with treating Verilog like a programming language, than describing a hardware logic design.

It looks like you are trying to use the array like a memory array in C than as a block of RAM or a bank of flip-flops.
Click to expand...

Yes,. I'm building a little processor to save some compilation time on an array of if statements.
So far it's hard to master with the rules verilog has in place. Trying to do workarounds with using always blocks.
Still it's a bit wonky, timing issues seem to creep in all over the place..
 

The point I was making is you need to know how to draw a schematic of the logic design as Verilog for synthesis (Hardware Description Language) is not a programming language.
 

ads-ee said:
The point I was making is you need to know how to draw a schematic of the logic design as Verilog for synthesis (Hardware Description Language) is not a programming language.
Click to expand...

Well it's not more efficient in synthesis anyway, so I went for the middle "goldylocks" zone in ease of coding vs serialism.
But I do think it's strange having to build a bus having a wire going to an array from a module. When you can just say, this array here.
 

Well you seem to know more about how Verilog should be coded than I do, so there isn't any point repling to this thread.
 

ads-ee said:
Well you seem to know more about how Verilog should be coded than I do, so there isn't any point repling to this thread.
Click to expand...

I dont know, im relatively new about the ins and outs of verilog "I do get it's not driving serial logic all the time". The case was I had a relatively big array of latches (40x5 or so if statements), and in my mind it would be a tight little logic unit if I had an array supplying values to it, having a reuasable logic unit on a counter. Slowing down non critical interactions on a 2mHz clock, to about 50kHz. Doing it on a local logic unit times 40. Seeing the output logic utilization. Im still out if im starting to figure out if that is not how synthesis works. Its kind of a dark path to follow. It seems either the total flat out version or the counted version using arrays is similar.

Please correct me if im wrong, It looks like using arrays does away with discrete values for latches, having more ambiguity rather than discrete routes.
Also in synthesis the number of states has not changed?, so in order to get logic utilization down the number of states has to go down rather than "logic surface area"?

- - - Updated - - -

So I was actually wrong also, both the flat out "discrete register" and counted "array" versions use a similar logic utilization. Using arrays in the medium version times 6, is the worst. Comparatively 13%-13% to 17%.
 
Last edited:

Register arrays are either implemented as block RAM or sea of individual flipflops (or even asynchronous latches), depending on which actual hardware is described in your Verilog code. It's rather easy to fail RAM inference because some strict prerequisites must be met.

They are set by the specific RAM hardware properties of the used FPGA family, preferably you refer to the documented RAM inference templates in the vendor HDL examples or synthesis guide. From what you have reported up to now about the register array connectivity in your design, I won't be surprised if it's not suited for RAM implementation without being restructured.
 

I do have uninferred ram. Info (276004): RAM logic "umux:UMX01|maxarray" is uninferred due to inappropriate RAM size
 

Size limit for automatic for automatic RAM inference can be adjusted in synthesis options.
 
FvM said:
Size limit for automatic for automatic RAM inference can be adjusted in synthesis options.
Click to expand...

I found the option, it didn't auto initalize it tho. I guess I need to initialize the M10K thing manually for this to work?
Need to fix my code first..
 

In my case I think it's better not to have inferred memory, since "I read" my design should have multiple read/writebacks in one clock. And that is not possible with M10k memory? Does this mean I should stear clear of using arrays all together?
 

No chance to use block RAM in this case. This also means that array addresses and data bus are only virtual and not actually implemented in your design. Instead a large number of logic cells is needed to multiplex the data path.
 
FvM said:
No chance to use block RAM in this case. This also means that array addresses and data bus are only virtual and not actually implemented in your design. Instead a large number of logic cells is needed to multiplex the data path.
Click to expand...

Exactly what I was trying to point out back in posts #4,6, & 8, but got shut down as
Well it's not more efficient in synthesis anyway, so I went for the middle "goldylocks" zone in ease of coding vs serialism.
Click to expand...
See what the middle "goldylock" zone (whatever the heck that is supposed to mean) gets you, an impossible to implement design, because you didn't draw the circuit before you started coding. Even now if the design gets complicated enough I draw at the minimum a detailed block diagram and determine how the circuit works before I start coding and I've been writing VHDL/Verilog for ~3 decades.

C like arrays are hard to synthesize in an FPGA unless they are specifically designed to be implemented in a RAM and yours wasn't. Yours would have to be done all in FFs and if the array is large it will take a long time to synthesize or may be impossible if it exceeds the number of FFs in the chosen part.
 
FvM; said:
No chance to use block RAM in this case. This also means that array addresses and data bus are only virtual and not actually implemented in your design. Instead a large number of logic cells is needed to multiplex the data path.
Click to expand...

Thanks! So if I understand correctly. Altho faster, using block RAM would complicate things like a write readback per clock cycle due to having a databus?

ads-ee said:
Exactly what I was trying to point out back in posts #4,6, & 8, but got shut down as
See what the middle "goldylock" zone (whatever the heck that is supposed to mean) gets you, an impossible to implement design, because you didn't draw the circuit before you started coding. Even now if the design gets complicated enough I draw at the minimum a detailed block diagram and determine how the circuit works before I start coding and I've been writing VHDL/Verilog for ~3 decades.

C like arrays are hard to synthesize in an FPGA unless they are specifically designed to be implemented in a RAM and yours wasn't. Yours would have to be done all in FFs and if the array is large it will take a long time to synthesize or may be impossible if it exceeds the number of FFs in the chosen part.
Click to expand...

I should convey these thins better :)
In case one there was a flat out times 36 nested if statement, with a times 6 latch. Using discrete registers.
Acting like a hub for multiple interactions coming from the outside world.
Which was a beast to maintain and took up 13% along with a little synthesizer.

The middle zone was 6 nested if statements and a latch, using arrays which worked fine but took up 17% "on a Cyclone 5 FPGA"

The latter "current version" uses a serial, 1 nested if statement and arrays and uses up 12%, bordering on 13%.
I only got it to work being very delicate with the data path. For me this one stands because of ease of access.
Only it lives due to a workaround. Not due to being counted through.
 

FvM said:
13% LEs of an A2 or A9 device?
Click to expand...

5CSEMA5F31C, A5 I think? 4.958 out of 32.070 ALM's, 750 registers. 15% by now. I do need to get parameters everywhere tho,
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top