Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
>Does it simulate OK? > >Sometimes the files need to be added in correct order, i.e. >the file with the package must be added before any library >units that make use of it. IIRC you can drag them around in the >gui to alter the order, or check the .prj file which should have >lines such as: >add_file -lib work my_pkg.vhd >add_file -lib work my_ent.vhd >etc. > >HTH -- Pontus > Hi, thanks for the answer. It simulates fine in Modelsim. It synthesises fine in Xilinx ISE. In Synplify, when I click "Run", it works fine until the Mapper process where another error happens. I've been wanting to run a Syntax and Synthesis check to investigate that error. I've moved my package up the list of files so it's the first one, and the error still happens. I've also ran the Compile Only (F7) option and it works fine! It even says that the synthax has been run successfully! Here are the logs for both options. Synthax Check : @N: CD720 :"C:\Synopsys\fpga_D201003\lib\vhd\std.vhd":123:18:123:21|Setting time resolution to ns @I:: "U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd" @W: CD643 :"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":10:26:10:26|Ignoring use clause - types_viterbi not found ... @E: CD255 :"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":14:42:14:42|No identifier "poids_size" in scope Compile Only : @N:CD720 : std.vhd(123) | Setting time resolution to ns @N: : decodeur_viterbi_carre.vhd(13) | Top entity is set to decodeur_viterbi_carre. VHDL syntax check successful! I'm at a loss as to what is causing the Synthax Check to fail. I'll continue to tinker with the different options and processes, but any further help/info would be appreciated. Isabelle LaRoche Université Laval Québec, Qc, Canada --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147301
On Apr 22, 1:15=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > Especially with ASIC you can't verify the design by testing. There are > so many signoff corners and modes in the timing analysis. The old > worst/best case in normal and testmode are long gone. Even 6 corner > analysis in 2+ modes is for low end processes with big extra margins. > With multiple adjustable internal voltage areas, powerdown areas etc. > the analysis is hard even with STA. For the record, I agree that lots of static analysis is necessary (static timing, model checking, etc.) The thesis when I started this sub-thread is that what the *language* gives you (VHDL vs. verilog) is such a small subset of possible checking as to be unuseful. I will now add that it comes at a huge cost (in coding things just right). Regards, PatArticle: 147302
On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote: .> Unfortunately, the source code is in Python :-) (MyHDL). > However, there is equivalent converted Verilog available > in the article. > > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2 Well, maybe it's so subtle I still don't get it. But it looks like 'run' and 'dir' are what I would consider combinatorial variables, so I would just stuff them in the combinatorial 'always @*' block. The only register which would have a corresponding 'next_' is 'q'. In fact, your whole sequential block could be converted to the combinatorial block (with the exception of changing '<=3D' to '=3D', and putting 'next_' in front of q on lhs), and the sequential block would basically be 'q <=3D next_q'. Or is there something else you're trying to convey that I'm missing? Regards, PatArticle: 147303
On Apr 22, 9:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote: > .> Unfortunately, the source code is in Python :-) (MyHDL). > > > However, there is equivalent converted Verilog available > > in the article. > > > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2 > > Well, maybe it's so subtle I still don't get it. =A0But it looks like > 'run' and 'dir' are what I would consider combinatorial variables, so > I would just stuff them in the combinatorial 'always @*' =A0block. =A0The > only register which would have a corresponding 'next_' is 'q'. =A0In > fact, your whole sequential block could be converted to the > combinatorial block (with the exception of changing '<=3D' to '=3D', and > putting 'next_' in front of q on lhs), and the sequential block would > basically be 'q <=3D next_q'. > > Or is there something else you're trying to convey that I'm missing? > > Regards, > Pat BTW, your myhdl does something similar, in that you use 'q.next'. So, I really don't understand why you would think it's a terrible thing to use 'next_q' to mean the same thing. Regards, PatArticle: 147304
On Apr 21, 6:26=A0am, John_H <newsgr...@johnhandwork.com> wrote: > Could you mention here or on your page what you mean by > "multipumping?" =A0If you mean time multiplexed access, I can see why > multipumping is bad. =A0[The "pure logic" approach also isn't obvious.] Yes, multipumping is time-multiplexing. It's not entirely bad, as there may be a speed margin leftover that you can trade for area using multipumping. Also, it is useful if you have few ports or low speed requirements. Pure logic refers simply to using only the reconfigurable fabric of the FPGA to implement the memory. It's not a very scalable solution. :) > Do you update the LVT in the same way I might update the RAM value in > a many-write BlockRAM? No. We've had several independent mentions of using XOR, but we hadn't heard of it at the time. We'll be looking at it in the future. The LVT is implemented in pure logic and has multiple read and write ports which can all work simultaneously. It remains practical because it is very narrow (log2(# of write ports) instead of full data word width). > Aside from wide data, however, I don't see (without going into the > attachments on that page) how updating the LVT is any different than > updating the memory in the first place. The LVT manages a bunch of Block RAMs with only one write and one read port, making them all behave as a single multiported memory. The LVT simply keeps track of which port last wrote to each address. Since the actual data is stored in Block RAMs, the end result is faster and more area efficient than other approaches. Please let me know if you have more questions. EricArticle: 147305
On Apr 22, 4:29=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 9:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
>
>
>
> > On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> > .> Unfortunately, the source code is in Python :-) (MyHDL).
>
> > > However, there is equivalent converted Verilog available
> > > in the article.
>
> > > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2
>
> > Well, maybe it's so subtle I still don't get it. =A0But it looks like
> > 'run' and 'dir' are what I would consider combinatorial variables, so
> > I would just stuff them in the combinatorial 'always @*' =A0block. =A0T=
he
> > only register which would have a corresponding 'next_' is 'q'. =A0In
> > fact, your whole sequential block could be converted to the
> > combinatorial block (with the exception of changing '<=3D' to '=3D', an=
d
> > putting 'next_' in front of q on lhs), and the sequential block would
> > basically be 'q <=3D next_q'.
>
> > Or is there something else you're trying to convey that I'm missing?
>
> > Regards,
> > Pat
>
> BTW, your myhdl does something similar, in that you use 'q.next'. =A0So,
> I really don't understand why you would think it's a terrible thing to
> use 'next_q' to mean the same thing.
The two are unrelated. q.next is MyHDL's way to do
signal (non blocking) assignment ("<=3D").
My critique is that you use 2 signals/regs per state register
instead of 1. You could also do that in MyHDL, but I'm not doing
that in the examples I showed you. BTW, it would look like:
next_q.next =3D q
Jan
Article: 147306Hi All, What is OFFSET In and OFFSET OUT ? Is it setup and hold time of Flip flop?. How to set a Offset in And offset out Constraints for a particular design? In synthesis report I'm seeing Minimum Input arrival time and Max.Output required time? whether it is equivalent to Offset in and Offset out ? Please give some idea about this. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147307
On Apr 22, 4:03=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote: > .> Unfortunately, the source code is in Python :-) (MyHDL). > > > However, there is equivalent converted Verilog available > > in the article. > > > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2 > > Well, maybe it's so subtle I still don't get it. =A0But it looks like > 'run' and 'dir' are what I would consider combinatorial variables, so > I would just stuff them in the combinatorial 'always @*' =A0block. =A0The > only register which would have a corresponding 'next_' is 'q'. =A0In > fact, your whole sequential block could be converted to the > combinatorial block (with the exception of changing '<=3D' to '=3D', and > putting 'next_' in front of q on lhs), and the sequential block would > basically be 'q <=3D next_q'. > > Or is there something else you're trying to convey that I'm missing? Yes, the fact that 'run' and 'dir' are state variables. Therefore, your proposed approach wouldn't work. You have the test vectors, you can try it yourself. Quoting from the article: """ This example is more subtle and complex than it may seem at first sight. As said before, variables dir and run are state variables and will therefore require a flip-flop in an implementation. However, they are also used =93combinatorially=94: when they change, they may influence the counter operation =93in the same clock cycle=94, that is, before the flip-flop output changes. This is perfectly fine behavior and no problem for synthesis tools, but it tends to confuse a lot of designers. """ JanArticle: 147308
On Apr 22, 10:52 am, Eric <eric.lafor...@gmail.com> wrote: > On Apr 21, 6:26 am, John_H <newsgr...@johnhandwork.com> wrote: > > > Could you mention here or on your page what you mean by > > "multipumping?" If you mean time multiplexed access, I can see why > > multipumping is bad. [The "pure logic" approach also isn't obvious.] > > Yes, multipumping is time-multiplexing. It's not entirely bad, as > there may be a speed margin leftover that you can trade for area using > multipumping. Also, it is useful if you have few ports or low speed > requirements. > > Pure logic refers simply to using only the reconfigurable fabric of > the FPGA to implement the memory. It's not a very scalable > solution. :) > > > Do you update the LVT in the same way I might update the RAM value in > > a many-write BlockRAM? > > No. We've had several independent mentions of using XOR, but we hadn't > heard of it at the time. We'll be looking at it in the future. The LVT > is implemented in pure logic and has multiple read and write ports > which can all work simultaneously. It remains practical because it is > very narrow (log2(# of write ports) instead of full data word width). > > > Aside from wide data, however, I don't see (without going into the > > attachments on that page) how updating the LVT is any different than > > updating the memory in the first place. > > The LVT manages a bunch of Block RAMs with only one write and one read > port, making them all behave as a single multiported memory. The LVT > simply keeps track of which port last wrote to each address. Since the > actual data is stored in Block RAMs, the end result is faster and more > area efficient than other approaches. > > Please let me know if you have more questions. > > Eric I guess I don't understand what you are accomplishing with this. Block rams in FPGAs are almost always multiported. Maybe not N way ported, but you assume they are single ported when they are dual ported. Can you give a general overview of what you are doing without using jargon? I took a look and didn't get it at first glance. RickArticle: 147309
Hi all, Can Quartus be persuaded to *output* an EDIF netlist of the design (at any point in the compilation)? Google returns lots of links about the EDIF import capabilities, but I can't see any on exporting! Why? I've started on an EDF reader for FPGAOptim so you can easily figure out what's going on with designs which don't fit in the device, from the Xilinx NGC file - using NGC2EDIF). It occurred to me that having EDIF input would make the tool useful for other FPGAs. While I'm at it, does Altera have an equivalent of Xilinx's XDL format? XDL is a low-level textual description of the configuration of the device in terms of what the LUTs are configured as, which of the config muxes are set, what routing is used etc. Thanks! Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html http://www.conekt.net/fpgaoptim.htmlArticle: 147310
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:uvdbjsabd.fsf@trw.com... > Hi all, > > Can Quartus be persuaded to *output* an EDIF netlist of the design > (at any point in the compilation)? Google returns lots of links about > the EDIF import capabilities, but I can't see any on exporting! I suspect not, even Mentor's Precision now generates a VQM file instead of EDIF for Altera, Hans www.ht-lab.com > > Why? I've started on an EDF reader for FPGAOptim so you can easily > figure out what's going on with designs which don't fit in the device, > from the Xilinx NGC file - using NGC2EDIF). It occurred to me that > having EDIF input would make the tool useful for other FPGAs. > > While I'm at it, does Altera have an equivalent of Xilinx's XDL > format? XDL is a low-level textual description of the configuration of > the device in terms of what the LUTs are configured as, which of the > config muxes are set, what routing is used etc. > > Thanks! > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technology > http://www.conekt.net/electronics.html > http://www.conekt.net/fpgaoptim.htmlArticle: 147311
On Apr 22, 12:36=A0pm, rickman <gnu...@gmail.com> wrote: > I guess I don't understand what you are accomplishing with this. > Block rams in FPGAs are almost always multiported. =A0Maybe not N way > ported, but you assume they are single ported when they are dual > ported. But what if you want more ports, say 2-write/4-read, without wait states? I assume them to be "simply dual-ported", which means one write port and one read port, both operating concurrently. It is also possible to run them in "true dual port" mode, where each port can either read or write in a cycle. Some of the designs in the paper do that. > Can you give a general overview of what you are doing without using > jargon? =A0I took a look and didn't get it at first glance. OK. Let me try: Assume a big, apparently multiported memory of some given capacity and number of ports. Inside it, I use a small multiported memory implemented using only the fabric of an FPGA, which stores only the number of the write port which wrote last to a given address. Thus this small memory is of the same depth as the whole memory, but much narrower, hence it scales better. When you read at a given address from the big memory, internally you use that address to look up which write port wrote there last, and use that information to steer the read to the correct internal memory bank which will hold the data you want. These banks are built-up of multiple Block RAMs so as to have one write port each, and as many read ports as the big memory appears to have. The net result is a memory which appears to have multiple read and write ports which can all work simultaneously, but which leaves the bulk of the storage to Block RAMs instead of the FPGA fabric, which makes for better speed and smaller area. Does that help? EricArticle: 147312
Hi, We are developing algorithm on a LYRTech ADC board. There are only 96 DSP48 on this board. We have a problem of DSP shortage with a FIR rcosine and low pass FIR design. There is a 105 MHz clock source with this board. I think a solution is to over clock DSP48 to improve performance. My question is how to double, triple or quadruple 105MHz on board clock. Can DCM do the trick? Then, how to get that? Thanks a lot.Article: 147313
On Apr 22, 2:53=A0pm, fl <rxjw...@gmail.com> wrote: > Hi, > We are developing algorithm on a LYRTech ADC board. There are only 96 > DSP48 on this board. We have a problem of DSP shortage with a FIR > rcosine and low pass FIR design. There is a 105 MHz clock source with > this board. I think a solution is to over clock DSP48 to improve > performance. My question is how to double, triple or quadruple 105MHz > on board clock. Can DCM do the trick? Then, how to get that? Thanks a > lot. This is a up-converter design from 25.1MSPS to 105MSPS. Any suggestions on the design? Thanks.Article: 147314
On Apr 22, 10:08=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote: > > Or is there something else you're trying to convey that I'm missing? > > Yes, the fact that 'run' and 'dir' are state variables. Therefore, > your > proposed approach wouldn't work. You have the test vectors, you can > try it yourself. > > Quoting from the article: > """ > This example is more subtle and complex than it may seem at first > sight. As said before, variables dir and run are state variables and > will therefore require a flip-flop in an implementation. However, they > are also used =93combinatorially=94: when they change, they may influence > the counter operation =93in the same clock cycle=94, that is, before the > flip-flop output changes. This is perfectly fine behavior and no > problem for synthesis tools, but it tends to confuse a lot of > designers. > """ OK, I admit I didn't read that carefully enough; in fact, I just glanced at the actual code before my coffee this morning. But you know what? Where I come from, "subtle" that "tends to confuse a lot of designers" is just a synonym for "screwed up." The whole point of the coding style I was describing is to NOT write stuff that would confuse other designers. After all, in C I can write perfectly valid code like "0[x] =3D 3". But just because I can, doesn't mean it's a good idea. Regards, PatArticle: 147315
Hi, The age old problem it seems data2mem and BMM files and I am stuck with a new problem I cant find the answer for. I have some generic ram in verilog which the xilinx software suite looks at and maps to two RAMB16s (higher two bytes and lower two bytes) so I have made a BMM file with the right names and widths depths etc Thats fine, it recognizes them and updates the _bd.bmm with the locations they have been mapped too. However the CPU does not turn over, I did a bit of digging and did a dump of working and non working BRAM data, it seems that on the working dump the higher two byte block is bit-shifted right 2 (I'm guessing because readmemh uses the parity as the lsbs). Is there a way I can tell data2mem that I want the parity on the other side or not atall so it inserts the code properly because its giving an offset when it inserts, its also interesting to note that the lower block matches perfectly? I have tried using RAMB18 but that didn't generate anything that looked right. Here is the working, two bit shifted, readmemh output: http://pastebin.com/0hgNpAnP and here is the non working data2mem, non bit shifted version: http://pastebin.com/Tcs3PJjZ Much thanks, BenArticle: 147316
On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe <jan@jandecaluwe.com> wrote: >On Apr 22, 4:03 pm, Patrick Maupin <pmau...@gmail.com> wrote: >> On Apr 22, 3:44 am, Jan Decaluwe <j...@jandecaluwe.com> wrote: >> .> Unfortunately, the source code is in Python :-) (MyHDL). >> >> > However, there is equivalent converted Verilog available >> > in the article. >> >> > http://www.myhdl.org/doku.php/cookbook:jc2 >> >> Well, maybe it's so subtle I still don't get it. But it looks like >> 'run' and 'dir' are what I would consider combinatorial variables, so >> I would just stuff them in the combinatorial 'always @*' block. The >> only register which would have a corresponding 'next_' is 'q'. In >> fact, your whole sequential block could be converted to the >> combinatorial block (with the exception of changing '<=' to '=', and >> putting 'next_' in front of q on lhs), and the sequential block would >> basically be 'q <= next_q'. >> >> Or is there something else you're trying to convey that I'm missing? > >Yes, the fact that 'run' and 'dir' are state variables. Therefore, >your >proposed approach wouldn't work. You have the test vectors, you can >try it yourself. > >Quoting from the article: >""" >This example is more subtle and complex than it may seem at first >sight. As said before, variables dir and run are state variables and >will therefore require a flip-flop in an implementation. However, they >are also used “combinatorially”: when they change, they may influence >the counter operation “in the same clock cycle”, that is, before the >flip-flop output changes. This is perfectly fine behavior and no >problem for synthesis tools, but it tends to confuse a lot of >designers. >""" I am not sure who is really confused here. What is suggested in the above paragraph is not really feasible; assuming by 'dir' one refers to the output of a flop. It's not possible to use the output of a flop at the same clock when its input changes (without generating an intentional hold violation by playing with clock skews). What one can do is to have a combinational signal dir_d which gets computed by dir_q and other signals. This dir_d can be used in the same clock cycle but dir_q will not be available till next cycle: if (left or dir_q) dir_d = 1; if (right) dir_d = 0; if (dir_d) do_left; dir_q <= dir_d; The problem with the last verilog block shown is the dir and run are not flops anymore but combinational signals decoded from goleft and goright so the last direction will not be remembered. If last direction needs to be remembered, one needs to decode the 'instruction', use the decoded value and remember the decoded value as above. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147317
Could you try to introduce an error in the package declaration, just to see that the compiler/analyzer is actually looking at the file you think its looking at?!? -- PontusArticle: 147318
On Apr 22, 9:11=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 22, 10:08=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote: > > > > > > Or is there something else you're trying to convey that I'm missing? > > > Yes, the fact that 'run' and 'dir' are state variables. Therefore, > > your > > proposed approach wouldn't work. You have the test vectors, you can > > try it yourself. > > > Quoting from the article: > > """ > > This example is more subtle and complex than it may seem at first > > sight. As said before, variables dir and run are state variables and > > will therefore require a flip-flop in an implementation. However, they > > are also used =93combinatorially=94: when they change, they may influen= ce > > the counter operation =93in the same clock cycle=94, that is, before th= e > > flip-flop output changes. This is perfectly fine behavior and no > > problem for synthesis tools, but it tends to confuse a lot of > > designers. > > """ > > OK, I admit I didn't read that carefully enough; in fact, I just > glanced at the actual code before my coffee this morning. =A0But you > know what? =A0Where I come from, "subtle" that "tends to confuse a lot > of designers" is just a synonym for "screwed up." Let me put it more correctly. Initially, I think, everyone is confused about this. I know I was (20 years ago already!). The confusion is resolved by a new insight: how RTL synthesis *really* works. Some get it quickly, others need more time. I think that's a common pattern with new paradigms. The benefit: a coding technique to solve real problems significantly more elegantly. > The whole point of the coding style I was describing is to NOT write > stuff that would confuse other designers. =A0After all, in C I can write > perfectly valid code like "0[x] =3D 3". =A0But just because I can, doesn'= t > mean it's a good idea. I suggest you try your coding style with my examples. You have the spec and test vectors. If you find your code much clearer, I don't have a case (with you) to argue further. Otherwise, you'll remember me when you start applying this technique in your designs :-) JanArticle: 147319
On Apr 22, 3:04=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe > >This example is more subtle and complex than it may seem at first > >sight. As said before, variables dir and run are state variables and > >will therefore require a flip-flop in an implementation. However, they > >are also used =93combinatorially=94: when they change, they may influenc= e > >the counter operation =93in the same clock cycle=94, that is, before the > >flip-flop output changes. This is perfectly fine behavior and no > >problem for synthesis tools, but it tends to confuse a lot of > >designers. > > I am not sure who is really confused here. What is suggested in the > above paragraph is not really feasible; assuming by 'dir' one refers > to the output of a flop. It's not possible to use the output of a flop > at the same clock when its input changes (without generating an > intentional hold violation by playing with clock skews). What one can > do =A0is to have a combinational signal dir_d which gets computed by > dir_q and other signals. This dir_d can be used in the same clock > cycle but dir_q will not be available till next cycle: I don't think Jan is confused. While I haven't actually simulated it, I have no reason to disbelieve that he has built a flop which feeds into a combinatorial network, and the only thing here with a name is the output of the combinatorial network, which also happens to feed back into the flop. Verilog will certainly let you do such things. And now (I think) I understand a bit better what Jan means by "register inferencing" -- in this case, this capability is manifested by the ability to not give a name to a register itself, but only to the combinatorial net feeding the register. When I first started using Verilog, I would do such things, and confuse myself and others mightily. So I stand by my opinion that having two distinct yet related names for the input and output of a hardware register makes it easier for someone to pick up some code and conceptualize what is going on and not get it wrong at first glance. FWIW, in a case like this, rather than having 'next_dir' and 'dir', I might use 'dir' and 'prev_dir'. So the start of the combinatorial block could have "dir =3D prev_dir", followed by conditionally setting dir as required. Then in the synchronous block, you would have "prev_dir =3D dir". As I originally mentioned, this style is a bit more verbose, but since code is read much more often than it is written, it is a net win. Regards, PatArticle: 147320
On Apr 22, 4:21=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote: > Let me put it more correctly. Initially, I think, everyone is confused > about this. I know I was (20 years ago already!). The confusion > is resolved by a new insight: how RTL synthesis *really* works. I got it. In fact, I used to do what you said, but sometimes I would be confused, or others would be. Haven't done that in 15 years. > Some get it quickly, others need more time. > I think that's a common pattern with new paradigms. That's an old paradigm. > The benefit: a coding technique to solve real problems > significantly more elegantly. But, in my previous experience, it doesn't. It just confuses people. > I suggest you try your coding style with my examples. You have the > spec and test vectors. If you find your code much clearer, I don't > have > a case (with you) to argue further. Otherwise, you'll remember me > when you start applying this technique in your designs :-) Been there, done that, got the t-shirt; somebody else showed me the light over a decade ago, and I never went back. Regards, PatArticle: 147321
On Tue, 20 Apr 2010 18:14:05 -0700 (PDT), Derek Simmons <dereks314@gmail.com> wrote: Completely off topic, but ... >I recently interviewed with a avionics company that uses [8031/8051] >for digital displays in the cockpit of the plane (it is easy to get >certfied for the FAA). I've never heard FAA certification described as "easy". Maybe they rubber-stamp for established vendors and members of the "old boys" club. From what I've heard wandering air shows, they actively prevent small businesses from entering the market. I don't have personal experience with FAA device cert ... I haven't built my plane yet and my pilot license so far has provided quite enough contact with them to satisfy my masochistic streak. However, I have dealt professionally with the FDA, and if the FAA is in any way similar they really ought to be a PITA. GeorgeArticle: 147322
Other than twice the declarations, unintentional latches, explicitly coding clock enables, simulation penalties, etc., using separate combinatorial and sequential blocks is just fine. Most designers here use single clocked processes / always blocks. Those that don't are 'encouraged' to. AndyArticle: 147323
On Apr 22, 5:32=A0pm, Andy <jonesa...@comcast.net> wrote: > Other than twice the declarations, unintentional latches, explicitly > coding clock enables, simulation penalties, etc., using separate > combinatorial and sequential blocks is just fine. Unintentional latches don't happen if you use a consistent naming style with, e.g. 'next_x' and 'x'. I don't think simulation penalties happen if the simulator is halfway decent. Twice the declarations is a slight issue, but if you do reg [2:0] x, next_x; it's not too bad at all. Explicitly coding clock enables -- not sure what you mean here -- that's an if statement no matter how you slice it. Regards, PatArticle: 147324
On Apr 22, 1:55=A0pm, Eric <eric.lafor...@gmail.com> wrote: > On Apr 22, 12:36=A0pm, rickman <gnu...@gmail.com> wrote: > > > I guess I don't understand what you are accomplishing with this. > > Block rams in FPGAs are almost always multiported. =A0Maybe not N way > > ported, but you assume they are single ported when they are dual > > ported. > > But what if you want more ports, say 2-write/4-read, without wait > states? > I assume them to be "simply dual-ported", which means one write port > and one read port, both operating concurrently. It is also possible to > run them in "true dual port" mode, where each port can either read or > write in a cycle. Some of the designs in the paper do that. > > > Can you give a general overview of what you are doing without using > > jargon? =A0I took a look and didn't get it at first glance. > > OK. Let me try: > > Assume a big, apparently multiported memory of some given capacity and > number of ports. Inside it, I use a small multiported memory > implemented using only the fabric of an FPGA, which stores only the > number of the write port which wrote last to a given address. Thus > this small memory is of the same depth as the whole memory, but much > narrower, hence it scales better. > > When you read at a given address from the big memory, internally you > use that address to look up which write port wrote there last, and use > that information to steer the read to the correct internal memory bank > which will hold the data you want. These banks are built-up of > multiple Block RAMs so as to have one write port each, and as many > read ports as the big memory appears to have. > > The net result is a memory which appears to have multiple read and > write ports which can all work simultaneously, but which leaves the > bulk of the storage to Block RAMs instead of the FPGA fabric, which > makes for better speed and smaller area. > > Does that help? > > Eric I appreciate the elaboration here in the newsgroup. The "true dual port" nature of the BlockRAMs allows one independent address on each of the two ports with a separate write enable for each port. The behavior of the BlockRAM can be modified to provide read data based on the new write data, old data, or no change in the read data value from last cycle (particularly helpful for multi-pumping). For an M write, N read memory, your approach appears to need M x (N+1) memories since you can have M writes all happening at the same time N accesses are made to the same "most recently written" memory. Please correct me if I'm wrong. This is the same number of memories required with the XOR approach but without the LVT overhead. The time delay in reading the LVT and multiplexing the memories feels like it would be cumbersome. While this might not add "wait states" it appears the system would not be able to run terribly quickly. XORs are pretty quick. There are always more ways to approach a problem that any one group can come up with. Kudos on your effort to bring a better approach to a tough system level issue for difficult designs.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z