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
Wastrel <stephensdigital@gmail.com> wrote: (snip, I wrote) >> As you might need a device driver to talk to USB to download >> the bitstream, that might be system dependent, such that it >> won't work. > The bitstream gets downloaded by Altium Designer via JTAG and that > part still works. Can you elaborate on the previous version of windows > option. As I mentioned earlier, running Quartus under Program > Files(x86) won't work becuase Quartus won't install under that > directory. Right click the program icon, properties, compatibility tab, and choose the version you want to be. As I understand it, this is what windows returns when the program asks which version it is running on. It seems that you want to do this for this installer, which is checking which version it is installing under. You might also do it to the installed program. -- glenArticle: 147351
You seem to put a lot of stock in the effortlessness of boilerplate, yet you prefer a language that is said to reduce the need for boilerplate. OK, so you mention that you could write a script to automate all of that, but to work, it would depend on a specific non-standard, non- enforceable naming convention. Not to mention this script has yet to be written and offered to the public, for free or fee. Which means each of those who would follow your advice must write, test, run and maintain their own scripts (or maybe even sell it to the rest of us, if they felt there was a market). Alas, we have no such scripts. So that would put most users back at typing out all that boilerplate. Once it is typed, there is no compiler to check it for you (unlike much of the boilerplate often attributed to vhdl). You recommend all of this extra work, rather than writing just one process, with none of your boilerplate (no additional process, no additional declarations, no additional assignments, no chances for latches, no simulation-slowing effects). What's really silly is how the two-process code model even got started. The original synthesis tools could not infer registers, so you had to instantiate them separately from your combinatorial code. Once the tools progressed, and could infer registers, the least impact to the existing coding style (and tools) was simply to replace the code that instantiated registers with code that inferred them, still separating that code from the logic code. Finally, someone (God bless them!) figured out how to do both logic and registers from one process with less code, boilerplate or not. For all your staunch support of this archaic coding style, we still have not seen any examples of why a single process style did not work for you. Instead of telling me why the boilerplate's not as bad as I think it is, tell me why it is better than no boilerplate in the first place. AndyArticle: 147352
On Fri, 23 Apr 2010 09:25:50 -0700 (PDT), Patrick Maupin wrote: > In any case, I posted elsewhere in this thread a >pointer to Cliff Cumming's paper on blocking vs non-blocking >assignments. I assume you've been studiously avoiding that for >plausible deniability Very droll. If you have had even half an eye on comp.lang.verilog these past few years you will have seen a number of posts clearly pointing out the very serious flaws in Cliff's otherwise rather useful paper. In particular, the "guideline" (=myth) about not using blocking assignments in a clocked always block was long ago exposed for the nonsense it is. Cliff is quite rightly highly respected in the industry, but he's no more infallible than the rest of us and he made a serious mistake (which, to his great discredit, he has never chosen to retract) on that issue. You have the freedom to choose your coding style, as we all do. You do yourself no favours by citing flawed "authority" as discrediting a style that you dislike. -- Jonathan BromleyArticle: 147353
On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel <stephensdigital@gmail.com> wrote: >On Apr 21, 1:08 pm, Jon Beniston <j...@beniston.com> wrote: >> It's running ok for me on Windows 7 64-bit. >> >> What particular part of the software are you having problems with? >> >> Jon > >Well it installs alright, but Altium Designer 6 can't find it - >whereas it did on my XP box. One problem is that Windows 7 likes to >put 32 bit legacy programs under Program FIles(x86), but Quartus won't >install there because it can't handle spaces or special characters in >it's filenames. Tell it to use the 8.3 name for the directory (one way of seeing this is to do a "dir /X" from a command prompt). For the directory above, the name would be "c:\progra~2\". -- Rich Webb Norfolk, VAArticle: 147354
On Apr 22, 8:25=A0pm, Wipster <benwhit...@gmail.com> wrote: > 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/0hgNpAnPand here is the non working data2mem, non > bit shifted version:http://pastebin.com/Tcs3PJjZ > > Much thanks, > Ben Just to give an update on this, I have found the problem. It seems that map connects 16 bits of the first RAMB16 as you would expect but then connects the parity of that block and 14 bits of the second RAMB16. Data2mem assumes parity bits are parity bits so the codewords where missing the top bits, this is corrected by going into the unrouted xdl and editing the connections back to connect to the 16 data bits of both. And there you go, hopefully they can fix this issue as its a time consuming correction. BenArticle: 147355
> Find the datasheets and (hopefully) all should become clear, thank you for the advice. I got the datasheet at last! i'll work on the details now. thank you againArticle: 147356
On Apr 23, 2:09=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > If you have had even half an eye on comp.lang.verilog > these past few years you will have seen a number of > posts clearly pointing out the very serious flaws in > Cliff's otherwise rather useful paper. =A0In particular, > the "guideline" (=3Dmyth) about not using blocking > assignments in a clocked always block was long > ago exposed for the nonsense it is. Well, I just did a search, and found some mild disagreements, but nothing that I would consider a "debunking." Perhaps you could point me to such? FWIW, I independently learned several of the lessons in Cliff's paper, so I find it handy to explain these lessons to others. So I really would be interested in a valid counterpoint, but I honestly didn't see it. Regards, PatArticle: 147357
On Apr 23, 1:26 pm, Andy <jonesa...@comcast.net> wrote: > You seem to put a lot of stock in the effortlessness of boilerplate, > yet you prefer a language that is said to reduce the need for > boilerplate. Not all boilerplate is created equal. In particular, some boilerplate is, not only easy to glance at and understand, but also, and more important, easy to code from first principles without knowing arcane corners of the language your are coding in. > OK, so you mention that you could write a script to automate all of > that, but to work, it would depend on a specific non-standard, non- > enforceable naming convention. Not to mention this script has yet to > be written and offered to the public, for free or fee. Which means > each of those who would follow your advice must write, test, run and > maintain their own scripts (or maybe even sell it to the rest of us, > if they felt there was a market). That's a good point. I have some languishing tools for this (because the boilerplate is never quite bad enough to work on the tools some more) that I should clean up and publish. > Alas, we have no such scripts. So that would put most users back at > typing out all that boilerplate. Once it is typed, there is no > compiler to check it for you (unlike much of the boilerplate often > attributed to vhdl). Well, actually, the stock verilog tools do a pretty darn good job these days. > What's really silly is how the two-process code model even got > started. The original synthesis tools could not infer registers, so > you had to instantiate them separately from your combinatorial code. > Once the tools progressed, and could infer registers, the least impact > to the existing coding style (and tools) was simply to replace the > code that instantiated registers with code that inferred them, still > separating that code from the logic code. That may well be. Nonetheless, many people found the two process method better, even before 'always @*' or the new systemverilog 'always_comb', to the point where they maintained ungodly long sensitivity lists. Are you suggesting that none of those people were reflective enough to try to figure out if that was the best way (for them) to code? > Finally, someone (God bless them!) figured out how to do both logic > and registers from one process with less code, boilerplate or not. Yes, and the most significant downside to this is that the access to the 'before clock' and 'after clock' versions of the same signal is implicit, and in fact, in some cases (e.g. if you use blocking assignments) you have access to more than two different signals within a process, all with the same name. There is no question that in many cases this is not an issue and the one process model will work fine. But I think most who do serious coding with the 'one process' model will, at least occasionally, wind up having two processes (either a separate combinatorial process, or two interrelated sequential processes) to cope with not having an explicit delineation of 'before clock' and 'after clock'. At the end of the day, it is certainly desirable to have something that looks more like the 'one process' model, but that gives explicit access to 'previous state' and 'next state', so that complicated combinatorial logic with interrelated variables can always be expressed inside the same process without resorting to weird code ordering that is done just to make sure that the synthesizer and simulator will create the structures you want. > For all your staunch support of this archaic coding style, we still > have not seen any examples of why a single process style did not work > for you. Instead of telling me why the boilerplate's not as bad as I > think it is, tell me why it is better than no boilerplate in the first > place. A paper I have mentioned in other posts, http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf gives some good examples why the general rule of never having blocking assignments in sequential blocks is a good practice. I have seen some dismiss this paper here, but haven't seen a technical analysis about why it's wrong. The paper itself speaks to my own prior experience, and I also feel that related variables should be processed in the same block. When I put this preference together with the guidelines from the paper, it turns out that a reliable, general way to achieve good results without thinking about it too hard is to use the two process model. But, if you can tell me that you *always* manage to put *all* related variables in the same sequential block, and *never* get confused about it (and never confuse any co-workers), then, as with KJ and Bromley and some others, you have no reason to consider the two process model. OTOH, if you sometimes get confused, or have easily confused co-workers, and/or find yourself using multiple sequential processes to model variables where multiple processes have references to variables in other processes, then you might want to consider whether slicing related functionality into processes in this fashion is really better than slicing the processes in a manner where you keep all the related functional variables together in a single combinatorial process, and simply extract out the registers into a very-well understood model. At the end of the day, I am willing to concede that the two process model is, at least partly, a mental crutch. Am I a mental cripple? In some respects, almost certainly. But on the off-chance that I am not the only one, I tolerate a certain amount of abuse here in order to explain to others who may also be easily confused that there are other coding styles than the single process model. I will also concede that the single process model can be beefed up with things like tasks or functions (similar to what Mike Treseler has done) to overcome some of the shortcomings. However, personally, I don't really find that to be any better than putting combinatorial stuff in a separate process. Regards, PatArticle: 147358
On Apr 23, 2:09=A0pm, Jonathan Bromley > You have the freedom to choose your coding > style, as we all do. =A0You do yourself no favours > by citing flawed "authority" as discrediting > a style that you dislike. BTW, I wasn't trying to cite "authority." I was trying to cite a paper which I've actually read and have no current reason to disagree with. You claim it's been debunked -- care to present a technical citation for such a claim? Regards, PatArticle: 147359
On Apr 23, 2:09=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > If you have had even half an eye on comp.lang.verilog > these past few years you will have seen a number of > posts clearly pointing out the very serious flaws in > Cliff's otherwise rather useful paper. =A0In particular, > the "guideline" (=3Dmyth) about not using blocking > assignments in a clocked always block was long > ago exposed for the nonsense it is. One last note: In researching this, I found a posting by you with rules and recommendations that I cannot disagree with: http://groups.google.com/group/comp.lang.verilog/msg/a87ba28b6d68ecc8 I will note that, if faithfully followed, the two process model can make it very easy to insure that none of these rules or guidelines are broken. Finally, as I have posted elsewhere, these rules combined with my personal preference to always update related variables inside the same always block, sometimes make it difficult to *not* use the two process model. Regards, PatArticle: 147360
(With apologies to Jan, I accidently emailed this first time to him instead of
posting... )
>>On Apr 22, 10:08 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>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 :-)
>
>Jan
Ok, coming in late. I'm a two always block designer. And I use
"variables". For me, it's an issue of how far away from the hardware
do you want to be.
I've done the block entirely in my coding style including
parameterizing the counter width, and naming conventions
(not simulated):
module jc2
#(
parameter WIDTH = 4;
)
(
input wire clk_i,
input wire goleft_i,
input wire goright_i,
input wire stop_i,
output reg [ WIDTH - 1 : 0 ] q_o
);
reg [ WIDTH - 1 : 0 ] next_q;
reg dir, next_dir;
reg run, next_run;
always @( posedge clk )
begin
q_o <= next_q;
dir <= next_dir;
run <= next_run;
end
always @*
begin
next_q = q_o;
next_dir = dir;
next_run = run;
if( goright_i )
begin
next_dir = 1'b0;
next_run = 1'b1;
end
else if( goleft_i )
begin
next_dir = 1'b1;
next_run = 1'b1;
end
if( stop_i )
next_run = 1'b0;
if( next_run )
begin
if( ~next_dir )
next_q = { ~q_o[ 0 ], q_o } >> 1;
else
next_q = { q_o, ~q_o[ WIDTH - 1 ] };
end
end
endmodule
Not much bigger than what's on your website for the myhdl code. Yes,
the top always block for the registers is overhead (above myhdl), but
I've got text editor macros to do that. Same for the default assign
of the next_* register to set my initial decode (and coincidentally
always prevent latches). The initial decode in this case is a
simple "stay in current state" but it doesn't have to be.
The benefit, to me, it's clearer. I know what's registers, what's
combinational. I also know that by using the "next_run", and
"next_dir" variables near the end of that combinational block
- instead of the state registers "run" and "dir" - I'm adding more
decode - I may have a critical path issue (Not likely in this trivial
example, but with large decodes...)
It comes down to what designers prefer. I like to "see in my head"
the logic I'm generating. The style above works for me quite well.
I get all the benefits that you tout about using "variables".
Others obviously wish to be more concise and use one always block.
They're allowed to. It's all a designers style.
Regards,
Mark
Article: 147361On Apr 23, 12:39=A0pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote: > On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel > > <stephensdigi...@gmail.com> wrote: > >On Apr 21, 1:08=A0pm, Jon Beniston <j...@beniston.com> wrote: > >> It's running ok for me on Windows 7 64-bit. > > >> What particular part of the software are you having problems with? > > >> Jon > > >Well it installs alright, but Altium Designer 6 can't find it - > >whereas it did on my XP box. One problem is that Windows 7 likes to > >put 32 bit legacy programs under Program FIles(x86), but Quartus won't > >install there because it can't handle spaces or special characters in > >it's filenames. > > Tell it to use the 8.3 name for the directory (one way of seeing this is > to do a "dir /X" from a command prompt). For the directory above, the > name would be "c:\progra~2\". > > -- > Rich Webb =A0 =A0 Norfolk, VA Rich and Glen, Thanks a lot for your help guys. I was able to install it under c: \progra~2 and direct windows to run it in XP service pack 3 compatibility mode. Unfortunately, now Altium throws a "Unsupported version of Altera Quartus II" message. Nice try though! Thanks again BobArticle: 147362
On Apr 23, 11:27=A0pm, gtw...@sonic.net (Mark Curry) wrote: > Ok, coming in late. =A0I'm a two always block designer. =A0And I use > "variables". =A0For me, it's an issue of how far away from the hardware > do you want to be. > > I've done the block entirely in my coding style including > parameterizing the counter width, and naming conventions > > It comes down to what designers prefer. =A0I like to "see in my head" > the logic I'm generating. =A0The style above works for me quite well. =A0 > I get all the benefits that you tout about using "variables". > Others obviously wish to be more concise and use one always block. > They're allowed to. =A0 It's all a designers style. Thanks for going through the effort of coding this up. As I said, if you really think this is clearer, I don't have a case to argue, although as you will expect I disagree. My original concern about raising the abstraction level still stands however. I agree that your style is closer to hardware; you will probably agree mine is at a slightly higher level of abstraction. So how are we supposed to raise the abstraction level significantly (something many clever people claim is urgently required) if we cannot even take a small step that is available today? Best regards, JanArticle: 147363
On Apr 22, 11:04=A0am, "newbab22" <kumar1983.s@n_o_s_p_a_m.gmail.com> wrote: > Hi 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 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Xilinx Timing Constraints User Guide http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ug612.pdfArticle: 147364
On Apr 19, 6:53=A0am, "Smith" <sm...@donotwantmail.com> wrote: > Hello all > > I need to run an old firmware for a Siemens SAB 80C537 microcontroller un= it > (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language.= It > would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem? My 2 cents. 1. The 537 comes in a 84-pin package, so finding a "modern" part with that much I/O is going to be a challenge, this was a top of the line 51-device in the late 80s 2. It has a MUL/DIV unit to accelerate 32/16 DIV and / or 16x16 MUL, much faster than a library. The only other device I know with the same MUL/DIV unit is the C509, unfortunately that one comes in a 100 pin package and is afaik a true superset of the 80C537. So, as pointed out, the lowest cost and by far fastest option is to find a broker. Hint: you can use the 80C517 as well because it is drop in compatible. The EA pin will always be connected for start from external memory when using a 80C537, so the 80C517 behaves EXACTLY like a 80C537 as long as the EA pin is not connected to the start from internal ROM option. Hope this helps, An Schwob Once upon a time I was an FAE supporting the 80C5x7, I know (knew?) these devices really well ;-) If it comes down to it to re-engineer or port to a different device and you need professional help, write me an e-mail to microcontroller addgmaildotcomArticle: 147365
On Apr 24, 11:08=A0am, An Schwob in the USA <schwo...@aol.com> wrote: > So, as pointed out, the lowest cost and by far fastest option is to > find a broker. > Hint: you can use the 80C517 as well because it is drop in compatible. > The EA pin will always be connected for start from external memory > when using a 80C537, so the 80C517 behaves EXACTLY like a 80C537 as > long as the EA pin is not connected to the start from internal ROM > option. Yes, the 80C517/80C517A may give him enough parts, to not need much Sw effort at all... -jgArticle: 147366
On Apr 23, 7:06=A0pm, kkoorndyk <kris.koorn...@gmail.com> wrote: > On Apr 22, 11:04=A0am, "newbab22" <kumar1983.s@n_o_s_p_a_m.gmail.com> > wrote: > > > Hi All, > > > What is OFFSET In and OFFSET OUT ? Is it setup and hold time of Flip fl= op?. > > How to set a Offset in And offset out Constraints for a particular desi= gn? > > > In synthesis report I'm seeing Minimum Input arrival time and Max.Outpu= t > > required time? whether it is equivalent to Offset in and Offset out ? > > > Please give some idea about this. > > > Thanks > > > --------------------------------------- =A0 =A0 =A0 =A0 > > Posted throughhttp://www.FPGARelated.com > > Xilinx Timing Constraints User Guide > > http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ug612... Also check out the blogs on the Xilinx forums: http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-3-of-5/ba-p/61= 885#A99Article: 147367
On Apr 23, 5:04=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> My original concern about raising the abstraction level still stands
> however. I agree that your style is closer to hardware; you will
> probably agree mine is at a slightly higher level of abstraction. So
> how are we supposed to raise the abstraction level significantly
> (something many clever people claim is urgently required) if we cannot
> even take a small step that is available today?
Well, it's hard for me to know what you are looking for in "raising
the abstraction level" when you showed the code this way. In my
opinion, coding run/stop and direction separately unnecessarily lowers
the abstraction level. I haven't given the actual design too much
thought, but I dashed out how I think I would approach this. I
haven't simulated or synthesized it, but I am confident that any bugs
in it would be quite easy to wring out. Also, all except the last few
lines are, again, what I personally consider "boilerplate" which
requires near-enough zero thought, so I don't see that they affect the
abstraction level too much. (But I would like to be able to get rid of
them, make no mistake!)
Note that this violates my preference not to use 'next_xxx' on the rhs
in one instance (but doesn't violate any of the underlying rules laid
out by Cliff Cummings), but given the choice between an extra variable
and this minor infraction (where it can be easily seen that next_state
is never used until all potential assignments to it have occurred), I
would probably code it as I have shown.
module johnson (
clk,
reset_n,
goLeft_n,
goRight_n,
stop_n,
q
);
parameter COUNTER_WIDTH =3D 4;
localparam COUNTER_TOP =3D COUNTER_WIDTH - 1;
localparam
STOP[1:0] =3D 2'b00,
RUNRIGHT[1:0] =3D 2'b01,
RUNLEFT[1:0] =3D 2'b10;
input clk;
input reset_n;
input goLeft_n;
input goRight_n;
input stop_n;
output [COUNTER_TOP:0] q;
reg [COUNTER_TOP:0] q, next_q;
reg [1:0] state, next_state;
always @(posedge clk or negedge reset_n)
if (!reset_n) begin
q <=3D 0;
state <=3D STOP;
end else begin
q <=3D next_q;
state <=3D next_state;
end
always @* begin
next_state =3D state;
next_q =3D q;
casez ({stop_n, goRight_n, goLeft_n})
3'b0??: next_state =3D STOP;
3'b10?: next_state =3D RUNRIGHT;
3'b110: next_state =3D RUNLEFT;
endcase
case (next_state)
RUNLEFT: next_q =3D {q, !q[COUNTER_TOP]};
RUNRIGHT: next_q =3D {!q[0], q[COUNTER_TOP:1]};
endcase
end
endmodule
BTW, if I read your code right, the casez above should match its
behavior. Personally, based on the description I read of the problem
(and if my probing of the customer indicated he didn't really care
about some of the edge conditions, because, for example, they
shouldn't occur), my preferred coding of this would probably be more
like:
next_state =3D STOP;
...
case ({stop_n, goRight_n, goLeft_n})
3'b111: next_state =3D state;
3'b101: next_state =3D RUNRIGHT;
3'b110: next_state =3D RUNLEFT;
endcase
Note also that, if all the variables are assigned a default next state
(which could be their previous state, or a constant, or an equation)
before any case statements or if/else statements, it is extremely easy
to verify, either manually or mechanically, that no latches have been
introduced.
It would be nice to get away from the boilerplate, and one of these
days I would like to get around to making something that would
reliably create and re-create the entire verilog file from
(essentially) the last few lines, maybe coded in a slightly different
style. I think it is doable.
Regards,
Pat
Article: 147368On Apr 22, 3:45=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > 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. =A0The 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. =A0Please > correct me if I'm wrong. =A0This is the same number of memories required > with the XOR approach but without the LVT overhead. =A0The time delay in > reading the LVT and multiplexing the memories feels like it would be > cumbersome. =A0While this might not add "wait states" it appears the > system would not be able to run terribly quickly. =A0XORs are pretty > quick. > > There are always more ways to approach a problem that any one group > can come up with. =A0Kudos on your effort to bring a better approach to > a tough system level issue for difficult designs. John_H, What is the XOR method in this regard? Can you give an explanation? or give a hint on the source? WengArticle: 147369
On Apr 23, 12:25 pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 23, 8:12 am, KJ <kkjenni...@sbcglobal.net> wrote: > > > The two process people generally do fall back on excuses about being > > misunderstood. > > Well, I'm not going to generalize about "one process people" but at > least some of them are supercilious bastards who think that anybody > who doesn't do things their way is an idiot. Name calling now...sigh... > > Hmmm...so you prefer to take what you admit as unnecessary > > chances....fair enough, that implies though that you expect some > > actual benefit from that decision...but are probably unable to come up > > with an actual example demonstrating that benefit. > > Well, I haven't used the single process style in many years, so no, I > can't point you directly to the issues I had that led me to switch. The implication in your earlier post was that you could...perhaps in the future you should consider not stating things that you can't actually back up in some fashion since at least in this sub-thread that inability has just led you to poor word choices. > But I have helped others to switch over they years, and they have all > been grateful. OK > In any case, I posted elsewhere in this thread a > pointer to Cliff Cumming's paper on blocking vs non-blocking > assignments. I assume you've been studiously avoiding that for > plausible deniability, so here it is: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf > Assuming something about other people is almost always a mistake. I've read Cummings' post before, but not being a Verilog guy and the issues he covers being very language specific it wasn't relevant to me in VHDL. <snip some Verilog commentary> > You can concentrate all your hard thinking on > the problem at hand, in the non-boilerplate code in the combinatorial > process. > VHDL using clocked processes and concurrent assignments avoids all boilerplate that is not checked by the compiler. There is no boilerplate executable design specific code at all. > > > but I could have some other hard to find logic problems, which > > > I *have* had in the past). > > > Ahhh....one of those examples...now what sort of 'hard to find' logic > > problem would you like to offer up to to the group to actually > > demonstrate that two processes are better than one? I'm willing to > > listen, but I'll warn that you that every time in the past that this > > debate pops up, the two process people are unable to coherently > > describe anything other than vague generalities as you've done > > here...so here is your opportunity to present a clear example > > describing a 'hard to find' logic problem that is easier to find when > > coded with two processes. The clocked process folks (i.e. the one > > process camp) have in the past presented actual examples to back their > > claims, Googling for 'two process' in the groups should provide some > > good cases. > > That's because you're *not* really willing to listen. Because you didn't say anything relevant to the point of presenting an example. > If you were, > you would have heard, from me, anyway, loud and clear, that it's not > really about the *language constructs*, it's about how much people can > hold in their heads at a single time. I agree and will add to that it's also about how much can fit on a screen so that it can be digested and kept in one's head...but I'll also add again that your response here in no way is directed to what I had asked which was "now what sort of 'hard to find' logic problem would you like to offer up...". Perhaps you should consider trying to make your repliess a bit more on topic rather than going on a tangent. > The two process method reduces > the need for that, so even if I presented an example where it helped > me in my thinking, you would just superciliously explain how any idiot > should have seen the error in the one process method, so it doesn't > prove anything. Again you wrongly assume a particular reaction from me and then use that incorrect assumption to provide yourself some personal justification for why you do not present anything to back up your claims...I'll leave it at that. > Since you're the smartest asshole in the world, the > two process method couldn't possibly offer any benefits you would be > interested in, so just forget about it. > More name calling and explicitly at me this time...you're distinguishing yourself in a rather unflattering manner > > - Producing less maintainable code (two process will always physically > > separate related things based only on whether the logic signal is a > > 'register' or not) > > See, this is another place where you haven't listened. What don't you > understand about 'boilerplate'? Apparently you've got your responses mixed up because nowhere in our little back and forth did we get into 'boilerplate' until you brought it up here, you and Andy were bantering boilerplate, not you and I...so, now who's not listening?? > It's a tiny bit of overhead, not > really part of what you need to worry about in maintenance. It is > easily checked and even automated. > Also completely avoidable (at least in VHDL). > BTW, this is the last > post I'm going to reply to you on OK, probably for the best. I won't wait for the apology for the name calling then. > so feel free to have fun with more > piling on. Asking for an example, is not demand for proof and certainly can't be considered to be 'piling on'. Kevin JenningsArticle: 147370
On Fri, 23 Apr 2010 20:09:45 +0100, Jonathan Bromley <spam@oxfordbromley.plus.com> wrote: >On Fri, 23 Apr 2010 09:25:50 -0700 (PDT), Patrick Maupin wrote: > >> In any case, I posted elsewhere in this thread a >>pointer to Cliff Cumming's paper on blocking vs non-blocking >>assignments. I assume you've been studiously avoiding that for >>plausible deniability > >Very droll. > >If you have had even half an eye on comp.lang.verilog >these past few years you will have seen a number of >posts clearly pointing out the very serious flaws in >Cliff's otherwise rather useful paper. In particular, >the "guideline" (=myth) about not using blocking >assignments in a clocked always block was long >ago exposed for the nonsense it is. > I think you're being overly harsh about this issue. The paper in question is almost 10 years old and synthesis tools came along way since then. Also one has to take the guideline within the context it has been defined. Here is the main justification stated in the paper: "A problem with blocking assignments occurs when the RHS variable of one assignment in one procedural block is also the LHS variable of another assignment in another procedural block and both equations are scheduled to execute in the same simulation time step, such as on the same clock edge. If blocking assignments are not properly ordered, a race condition can occur. When blocking assignments are scheduled to execute in the same time step, the order execution is unknown." If one considers that the guidelines are usually there for novices I don't think it's too much to say blocking assignments should not be used for sequential logic. You have to keep in mind that the use you're advocating is only applicable for regs which are local to the always block where no other always block can get at them. So the appropriate use of blocking statements in a clocked always block comes with a pretty strict constraint. As the guideline, as stated, has no constraints it should be considered more than half valuable. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147371
On Apr 23, 10:03=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > Assuming something about other people is almost always a mistake. > I've read Cummings' post before, but not being a Verilog guy and the > issues he covers being very language specific it wasn't relevant to me > in VHDL. Well, I will apologize about one thing. In some of my earlier posts, I restricted my replies to not include comp.lang.vhdl, but I didn't on this sub-thread, so this "leaked" into that newsgroup without me paying adequate attention. So I apologize for assuming that you knew verilog and that you had seen my other posts that did not make it into comp.lang.vhdl. Verilog was the framing point for the one process/two process discussions I was having. The Cummings paper adequately describes several of the bad things that can happen in Verilog if you aren't paying close attention (that the two process model can help alleviate), so that is why I did not feel compelled to provide a similar example. As far as the rest of it goes, you had the chance in multiple posts to step back and say to yourself that you must be misunderstanding me, but in all cases you chose to assume I was a complete idiot. This is certainly a distinct possibility (perhaps even a probability), but the assumption of it starting out did not lead to a fruitful discussion, and, in fact, it was only in your reply to my name-calling that you have given me the chance to see how we are talking past each other. Regards, PatArticle: 147372
On Apr 23, 10:43=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > I think you're being overly harsh about this issue. The paper in > question is almost 10 years old and synthesis tools came along way > since then. Also one has to take the guideline within the context it > has been defined. FWIW, the latest rev of the paper (1.3) was September of last year. Regards, PatArticle: 147373
On 23 Apr, 18:19, Wastrel <stephensdigi...@gmail.com> wrote: > On Apr 21, 1:08=A0pm, Jon Beniston <j...@beniston.com> wrote: > > > It's running ok for me on Windows 7 64-bit. > > > What particular part of the software are you having problems with? > > > Jon > > Well it installs alright, but Altium Designer 6 can't find it - > whereas it did on my XP box. So could that not be a problem with AD6, rather than Quartus? > One problem is that Windows 7 likes to > put 32 bit legacy programs under Program FIles(x86), but Quartus won't > install there because it can't handle spaces or special characters in > it's filenames. There is an option to say where you want to install it which worked fine for me. JonArticle: 147374
> > I need to run an old firmware for a Siemens SAB 80C537 > > microcontroller unit > > (MCU). The MCU is now obsolete (it's from the late 1980s). > > > > The firmware is compiled from several thousand rows of assembly > > language. It > > would take a long time to understand the code and re-program it in > > C. Consider emulating the 8051 in software rather than fpga firmware. While it won't be as fun, it'll be easier to debug and maintain. I expect there open sources for both kinds of emulation. The hard part will be the peripherals. Hope you hava a data book. -- mac the naïf
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