Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 147350

Article: 147350
Subject: Re: Quartus II under Windows7?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 23 Apr 2010 18:25:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 147351
Subject: Re: I'd rather switch than fight!
From: Andy <jonesandy@comcast.net>
Date: Fri, 23 Apr 2010 11:26:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Andy

Article: 147352
Subject: Re: I'd rather switch than fight!
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Fri, 23 Apr 2010 20:09:45 +0100
Links: << >>  << T >>  << A >>
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 Bromley

Article: 147353
Subject: Re: Quartus II under Windows7?
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Fri, 23 Apr 2010 15:39:27 -0400
Links: << >>  << T >>  << A >>
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, VA

Article: 147354
Subject: Re: Problem with data2mem
From: Wipster <benwhitten@gmail.com>
Date: Fri, 23 Apr 2010 12:45:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Ben

Article: 147355
Subject: Re: confusion with ADC/DAC interface implementation
From: alkosd@yahoo.co.uk
Date: Fri, 23 Apr 2010 13:00:22 -0700 (PDT)
Links: << >>  << T >>  << A >>

> 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 again

Article: 147356
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 13:19:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 147357
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 13:29:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 147358
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 13:32:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 147359
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 14:15:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 147360
Subject: Re: I'd rather switch than fight!
From: gtwrek@sonic.net (Mark Curry)
Date: 23 Apr 2010 21:27:23 GMT
Links: << >>  << T >>  << A >>
(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: 147361
Subject: Re: Quartus II under Windows7?
From: Wastrel <stephensdigital@gmail.com>
Date: Fri, 23 Apr 2010 14:58:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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

Bob

Article: 147362
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 23 Apr 2010 15:04:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,

Jan

Article: 147363
Subject: Re: OFFSET and OFFSET out
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Fri, 23 Apr 2010 16:06:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.pdf


Article: 147364
Subject: Re: Need to run old 8051 firmware
From: An Schwob in the USA <schwobus@aol.com>
Date: Fri, 23 Apr 2010 16:08:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
addgmaildotcom

Article: 147365
Subject: Re: Need to run old 8051 firmware
From: -jg <jim.granville@gmail.com>
Date: Fri, 23 Apr 2010 16:36:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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...

-jg

Article: 147366
Subject: Re: OFFSET and OFFSET out
From: Gabor <gabor@alacron.com>
Date: Fri, 23 Apr 2010 18:13:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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#A99

Article: 147367
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 18:26:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 147368
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 23 Apr 2010 19:39:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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?

Weng

Article: 147369
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 23 Apr 2010 20:03:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Jennings

Article: 147370
Subject: Re: I'd rather switch than fight!
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 23 Apr 2010 20:43:52 -0700
Links: << >>  << T >>  << A >>
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.com

Article: 147371
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 20:49:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 147372
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 20:55:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 147373
Subject: Re: Quartus II under Windows7?
From: Jon Beniston <jon@beniston.com>
Date: Sat, 24 Apr 2010 06:26:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Jon


Article: 147374
Subject: Re: Need to run old 8051 firmware
From: mac <alex.colvin@valley.net>
Date: Sat, 24 Apr 2010 15:45:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
> > 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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search