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 105450

Article: 105450
Subject: Re: Why 8 clock trees in Xilinx Spartan-3 device?
From: "Tim" <tim@rockylogiccom.noooospam.com>
Date: Sun, 23 Jul 2006 18:43:39 +0100
Links: << >>  << T >>  << A >>

8 clock trees implemented because you could often use 9. Many thanks to 
Xilinx for not implementing 16 trees or Murphy would dictate 17 and any 
number > 1 is potential trouble. 



Article: 105451
Subject: ANN: MicroBlaze simulator available
From: "Antti" <Antti.Lukats@xilant.com>
Date: 23 Jul 2006 10:58:15 -0700
Links: << >>  << T >>  << A >>
Hi

after some while MicroBlaze uClinux ready simulator is again available

http://www.xilant.com/downloads/xsim_1_0.zip
some screenshot is here
http://xilant.com/content/view/44/2/

all ready to run,
included are a few uclinux demo images (2.4.29 and 2.4.32)
and also u-boot 1.1.14

MicroWindows tuxchess demo also included :)

note that this is very prelim version - but several people have asked
about the
availabilty of the simulator so I made the early version available

Antti


Article: 105452
Subject: Re: Why 8 clock trees in Xilinx Spartan-3 device?
From: "fp" <fpga002006@yahoo.com>
Date: 23 Jul 2006 12:54:54 -0700
Links: << >>  << T >>  << A >>
Thank everyone for replies.  The info is helpful.

There is one follow-up question for Austin.  In Spartan-3 family, most
hardware resource increases as the device becomes larger.  If we
compare 3S50 and 3S5000:
 - system gate: 50K vs 5M
 - block ram bit: 72K vs 1872K
 - multiplier: 4 vs 104
 - user I/O: 124 vs 784

However, the number of clock tree remains the same (8) for all devices.
Is there a reason for this?

Thanks in advance.

S. C.


>Austin Lesea wrote:
> S. C.
>
> One use I was given is that there is more than one design in the chip.
> Sort of like an apartment building, with different tenants.
>
> Another use is for standard interfaces which you do not get to choose
> the frequency:  SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78
> MHz, all working together to perform some overall function.
> 
> Austin
> 
> >


Article: 105453
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 23 Jul 2006 13:01:40 -0700
Links: << >>  << T >>  << A >>
PeteS,

There is one thing you are missing:  the package.  You have no control 
over that.

The value is less important.  "A good match" is between 2:1.  Really. 
Just run the simulations and you can see that happenening.

Your tricks with the pcb are all lost because the package has a 1" long 
50 ohm trace in it, with a capacitive load at its end (the transistors 
in their off state - not driving).

If only the pad to the die where directly mounted to the pcb.  But that 
is not possible with the die we have today (with as many as 1700 pcb 
bumps, and perhaps more than 10,000 package bumps).

Austin

PeteS wrote:

> Austin Lesea wrote:
> 
>>All,
>>
>>Any external resistor, no how well implemented is ever as good as an
>>internal termination.  It has to do with the short stub to the resistor
>>which is unavoidable being a source of reflections.
> 
> 
> True in a literal sense, provided one can get the precision, which is
> not that easy in a standard IC.
> That said, the parasitics you refer to are not an issue for an 0402
> device at 5Gb/s signalling (far higher speeds than the OP desires to
> deal with in this case) - any such parasitics are swamped by other
> issues of moving a signal across ciruit board (depends on the specific
> circuit board, of course, but in this case I expect the project to be
> FR-4 based).
> 
> There are methods of dealing with the 'stub' (by necking the track to
> the pad and trickery with adjacent grounds on the same layer) which
> reduce it to the realm of effectively non-existent.
> 
> For this particular case, if you look at the part I suggested, the only
> discontinuity would be at the ball itself, and that is a minor issue.
> 
> Cheers
> 
> PeteS
> 
> 
> 
>>That aside, the DCI for SSTL/HSTL is a resistance to ground from the
>>rails, so it uses power (more than 200 IO's and we are talking some
>>serious number of watts).
>>
>>Have you considered using LVCMOS DCI in a bidirectional mode?
>>
>>If you would like to see a signal integrity program result, email me
>>directly (or request one from the hotline).
>>
>>Talking about it won't solve your problem.  You have to do some real SI
>>engineering for any custom IO requirement.  In my opintion, it should be
>>done for any IO requirement.
>>
>>Austin
>>
>>Austin
>>
>>PeteS wrote:
>>
>>
>>>John Adair wrote:
>>>
>>>
>>>>Your biggest issue is not the top surface area for the resistor site
>>>>but the via space and extra routing needed to connect resistors. The
>>>>vias especially will have significant routing effects. Even using a
>>>>microvia blocks the path for potentially an extra signal. Conventional
>>>>vias block 2 traces worth in our standard technology. BGA resistor
>>>>packs whilst small tend not to have a good run of routing them and
>>>>generally increase layer count to achieve the end result.
>>>>
>>>>John Adair
>>>>Enterpoint Ltd.
>>>
>>>
>>>Depends on what is being routed, of course.
>>>
>>>In this particular application, the signal can go in and out very
>>>easily (1 track between balls for each ball position) and no vias at
>>>all are required.
>>>
>>>In a parallel termination case, things are different, but for a series
>>>terminator, the devices I have used work just fine with no extra layer
>>>count required. Indeed, the part manufacturers are aware of the issue
>>>that saving space for the package but providing poor access negates any
>>>advantage of the package size, so parts are appearing that have decent
>>>routing ability.
>>>
>>>Cheers
>>>
>>>PeteS
>>>
>>>
>>>
>>>
>>>>PeteS wrote:
>>>>
>>>>
>>>>>John Adair wrote:
>>>>>
>>>>>
>>>>>>Standards like SSTL are good for this due to the low signal swing. The
>>>>>>biggest decision is if to use DCI which burns more power in the V4 or to use
>>>>>>external resistors which take board area and make routing more difficult.
>>>>>>
>>>>>>The other decision is weither you use source synchronous clocking or a
>>>>>>common clock approach. At 150 Mhz the common clock is slightly marginal
>>>>>>depending on how long tracks are, speed grade, etc. unless you use some DCM
>>>>>>based techniques. You can generate a clock that is offset from the common
>>>>>>clock a little by using a DCM and use that as clock for register input to
>>>>>>gain more time. Alternatively you can use a DCM to null out the clock to
>>>>>>output time and get more margin from that.
>>>>>>
>>>>>>John Adair
>>>>>>Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development
>>>>>>Board.
>>>>>>http://www.enterpoint.co.uk
>>>>>>
>>>>>>
>>>>>>"Marc Reinig" <Marco@newsgroups.nospam> wrote in message
>>>>>>news:44bc1fed@darkstar...
>>>>>>
>>>>>>
>>>>>>>I have a project where I will have a large array of V4 FPGAs.  Each chip is
>>>>>>>intended to connect to its four orthogonal neighbors with no intervening
>>>>>>>logic.  I would like the number of bus connections between chips in any
>>>>>>>direction in the array to be 150 (600 total I/O per chip).  The connections
>>>>>>>will be bi-directional.  The distance between chips will be the minimum I
>>>>>>>can have with sockets, heat sinks (with individual fans), good layout and
>>>>>>>noise control.  Some of the lines, what ever is necessary, will be used for
>>>>>>>clock and framing for the bus data signals.  I would like to use DDR.
>>>>>>>During bus transfers, all the lines on opposite sides of the chip will be
>>>>>>>operating and the other two sides will be quiescent.  I'm hoping for a bus
>>>>>>>clock of 150 MHz.
>>>>>>>
>>>>>>>
>>>>>>>Comments? ;=)
>>>>>>>
>>>>>>>Marco
>>>>>>>________________________
>>>>>>>Marc Reinig
>>>>>>>UCO/Lick Observatory
>>>>>>>Laboratory for Adaptive Optics
>>>>>>>
>>>>>>>
>>>>>
>>>>>If Marc uses SSTL, and uses resistive terminators, I would agree it
>>>>>takes board space, but I disagree it would make routing significantly
>>>>>more difficult, except for the sheer number of devices. In a point to
>>>>>point situation only a series terminator is really required for speeds
>>>>>up to at least 200MHz / 400Mb/s (I've done it).
>>>>>
>>>>>Assuming these busses would be bidirectional, external series resistors
>>>>>would [arguably, at least] actually be better in reducing EMI and
>>>>>reflections than just DCI (less power too) assuming the devices are
>>>>>close together (of the order of perhaps 4 inches or less). Much really
>>>>>depends on the distance. I've used BGA style resistor packs that cram
>>>>>more resistors into the device than can be done in multipack type SMT
>>>>>devices. Apart from that, the tiny quad pack devices are particularly
>>>>>sensitive to even slightly imperfect chip shooters and have a nasty
>>>>>tendency to crack the resistor, particularly at the ends of the device.
>>>>>
>>>>>CTS corp makes a particularly nice range of devices
>>>>>(http://www.ctscorp.com/components/clearone.asp) [I have no affiliation
>>>>>with them except for having used the parts in the past].
>>>>>
>>>>>Cheers
>>>>>
>>>>>PeteS
>>>
>>>
> 

Article: 105454
Subject: Microblaze: how to determine remainder after integer division
From: "eejw" <wilder_joel@hotmail.com>
Date: 23 Jul 2006 14:31:48 -0700
Links: << >>  << T >>  << A >>
Hello all,

Fairly new user to Xilinx microblaze here (and first post to this user
group).  I'm trying to write C-code (within Xilinx Platform Studio) to
determine the remainder after an integer division.  So if I say

num = 13/10;
rem = 13%10;

then num = 1 and rem = 3.

I'm getting an error stating "invalid operands to binary %" when I try
to build.

What I surmise is that % is trying to convert to a binary format rather
than obtaining the desired remainder result.  I would also assume that
I need to include the correct header file in order to perform the
remainder operation.

However, I'm having trouble determining what math functions are
available w/in microblaze and the associated symbols needed to perform
desired functions (i.e., how to determine an integer remainder).

When I'm configuring microblaze in fpga hardware, should I use floating
point?  I can't find any math include file under
<design>/microblaze_0/include.

Thanks for the help in figuring this out.  I'm sure there's an easy
answer...


Article: 105455
Subject: Re: Why 8 clock trees in Xilinx Spartan-3 device?
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 23 Jul 2006 17:45:50 -0700
Links: << >>  << T >>  << A >>
Yes,

It is called "simplicity."

If the clock tree were to vary, it would make the assembly of each 
family member part even more of a hassle (than it already is), and the 
software would also have to be "different" for each member of the fanily 
(more than it already is).

Thus, to make the resource the same for the smallest or largest part may 
be seen as a waste, yet it is the only practical way to manufacture a 
family of devices, and support them.

The same is true for the routing resources:  a small part does not 
"need" all we provide, and a "large" part has perhaps too little (for 
some designs).

Austin

fp wrote:

> Thank everyone for replies.  The info is helpful.
> 
> There is one follow-up question for Austin.  In Spartan-3 family, most
> hardware resource increases as the device becomes larger.  If we
> compare 3S50 and 3S5000:
>  - system gate: 50K vs 5M
>  - block ram bit: 72K vs 1872K
>  - multiplier: 4 vs 104
>  - user I/O: 124 vs 784
> 
> However, the number of clock tree remains the same (8) for all devices.
> Is there a reason for this?
> 
> Thanks in advance.
> 
> S. C.
> 
> 
> 
>>Austin Lesea wrote:
>>S. C.
>>
>>One use I was given is that there is more than one design in the chip.
>>Sort of like an apartment building, with different tenants.
>>
>>Another use is for standard interfaces which you do not get to choose
>>the frequency:  SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78
>>MHz, all working together to perform some overall function.
>>
>>Austin
>>
>>
> 

Article: 105456
Subject: ByteBlasterMV?
From: Clifford Heath <no@spam.please.net>
Date: Mon, 24 Jul 2006 15:45:13 +1000
Links: << >>  << T >>  << A >>
While looking for a circuit for an Altera ByteBlasterMV,
I found this one for an original BB:
<http://opencollector.org/history/freecore/Build%20your%20own%20ByteBlaster!.htm>

The MV uses a 74HC244 instead of the LS one, and that means
that the unused inputs need to be pulled high. But with the
'244 running at 3.3v, for example, won't the parallel port
cause latchup by pulling the inputs too high? Is it ok to
connect the inputs using series resisters to avoid that?
What value should I use?

Any other changes needed to make this work at 3v3 with an
EPM3064?

Clifford Heath.

Article: 105457
Subject: Re: Hardware book like "Code Complete"?
From: Ian Bell <ruffrecords@yahoo.com>
Date: Mon, 24 Jul 2006 07:46:07 +0100
Links: << >>  << T >>  << A >>
Davy wrote:

> Hi all,
> 
> Is there some hardware RTL book like "Code Complete" by Steve
> McConnell?
> 

Unlikely. Creating software is far less complex and variable than creating
hardware.

Ian


Article: 105458
Subject: ROM implementation
From: "gollum" <etoktas@gmail.com>
Date: 24 Jul 2006 00:17:40 -0700
Links: << >>  << T >>  << A >>
I have a 256x8 bit look up table in my vhdl design and I reach this
look up table 64 times.

I am using Synplify 8.6.1 to synthesize my code for ACTEL Ax or Proasic
family and tool infers a lot of ROMs for this table.

As soon as I understand this inferred ROMs are made up of logic gates
not reserved block Rams in the technology.

I heard that there is an attribute for Xilinx Virtex family named
"select_ROM" in order to use block Rams instead of wasting logic gates
of resources.

Is there any attribute for Actel family?


I would appreciate your help.


Article: 105459
Subject: Re: version control of ISE+EDK projects with CVS and/or SVN
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 24 Jul 2006 01:11:52 -0700
Links: << >>  << T >>  << A >>
I am afraid, the only way to find out, is to partly delete files and
try to reconstruct in order fo find out, what can be thrown away and
what should be kept.


Article: 105460
Subject: Re: ROM implementation
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 24 Jul 2006 02:02:13 -0700
Links: << >>  << T >>  << A >>
Hi,

try the following:

signal ls_rom_out : std_logic_vector(... downto 0);

attribute syn_romstyle : string;
attribute syn_romstyle of ls_rom_out : signal is "select_rom";

I do not know whether it can be applied with Actel devices ...

Rgds
Andr=E9


Article: 105461
Subject: Re: version control of ISE+EDK projects with CVS and/or SVN
From: Sean Durkin <smd@despammed.com>
Date: Mon, 24 Jul 2006 11:40:37 +0200
Links: << >>  << T >>  << A >>
manu wrote:
> Hello,
> for the moment, I use SVN to manage different versions of te VHDL code
> of my projects.
> I'd like to manage my xilinx projects based on my VHDL code too.
> Until now, I just put the <project>.ise and <project>.ucf files under
> version control and it was enough to be rebuild the whole project.
> Now, I've added an embedded processor to my ISE design and I'm a bit
> confused because there a huge set of automatically generated files. I'd
> like to keep under version control just the minimum set of files
> required to rebuild the whole project. I think there's at least the
> <project_up>.xmp, <project_up>.mhs and <project_up>.mss files, but is it
> enough ?
Theoretically, those should be enough, plus your pcores-directory (in
case you have created your own peripherals) and the directory where you
store your application code (the C-code for your program).

Putting anything else in the repository will not work smoothly, because
EDK deletes whole directory trees when you clean up the project to have
it synthesize again.

The implementation directory for example... usually I would like to
check in the created netlist files, but once you re-run the EDK flow,
EDK deletes the directory including the hidden CVS directories, so your
usual CVS client gets really confused...

cu,
Sean

Article: 105462
Subject: chipscope opb monitor
From: Frank van Eijkelenburg <someone@work.com.invalid>
Date: Mon, 24 Jul 2006 12:24:04 +0200
Links: << >>  << T >>  << A >>
I try to use the opb/iba unit of chipscope to monitor the opb bus within a 
simple edk design. I took the chipscope lab example as start point. I am able to 
see the OPB signals in chipscope, but I can not set a trigger point. For 
example, I want to trigger at a certain address 0xFFFFXXXX. If I wait for the 
triggercondition, the behaviour is the same if no condition is set (like the 
immediate trigger button is clicked). Another problem is: I don't see assembly 
or c-source code in the listing window. Do I have to tell chipscope where it can 
find sources? What could be wrong?

In the lab example there are three control ports instantiated at the ICON unit 
while only two ports are connected. I have two control ports instantiated and 
connected, because ISE failed at the unconnected control port (in the map phase).

Any ideas?
Frank

Article: 105463
Subject: Re: ROM implementation
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 24 Jul 2006 10:36:24 GMT
Links: << >>  << T >>  << A >>

"gollum" <etoktas@gmail.com> wrote in message 
news:1153725459.998815.222190@i42g2000cwa.googlegroups.com...
>I have a 256x8 bit look up table in my vhdl design and I reach this
> look up table 64 times.
>
> I am using Synplify 8.6.1 to synthesize my code for ACTEL Ax or Proasic
> family and tool infers a lot of ROMs for this table.
>
> As soon as I understand this inferred ROMs are made up of logic gates
> not reserved block Rams in the technology.
>
> I heard that there is an attribute for Xilinx Virtex family named
> "select_ROM" in order to use block Rams instead of wasting logic gates
> of resources.

If you're using VHDL you might consider using LPM_ROM instead of however it 
is you've coded your table in the code.  LPM is a standardized set of 
functions (Library of Parameterizable Modules...or something like that) that 
will make your code portable and totally avoid use of vendor specific 
attributes.

KJ 



Article: 105464
Subject: Re: ByteBlasterMV?
From: "Leon" <leon.heller@bulldoghome.com>
Date: 24 Jul 2006 06:03:41 -0700
Links: << >>  << T >>  << A >>

Clifford Heath wrote:
> While looking for a circuit for an Altera ByteBlasterMV,
> I found this one for an original BB:
> <http://opencollector.org/history/freecore/Build%20your%20own%20ByteBlaster!.htm>
>
> The MV uses a 74HC244 instead of the LS one, and that means
> that the unused inputs need to be pulled high. But with the
> '244 running at 3.3v, for example, won't the parallel port
> cause latchup by pulling the inputs too high? Is it ok to
> connect the inputs using series resisters to avoid that?
> What value should I use?
>
> Any other changes needed to make this work at 3v3 with an
> EPM3064?

I've designed a similar unit using a 74HC244. In theory, there could be
a problem, but mine works fine with 3.3V devices. I've sold a few of
them, as well. I think that a 74AC244 might be better.

Leon


Article: 105465
Subject: Re: Why 8 clock trees in Xilinx Spartan-3 device?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 24 Jul 2006 14:24:01 +0100
Links: << >>  << T >>  << A >>
"fp" <fpga002006@yahoo.com> writes:

> Synchronous design, in which all FFs are synchronized by a single
> clock, perhaps is the single most important methodology.  In a Xilinx
> Spartan-3 FPGA, there are 8 clock trees, even for the smallest device.
> What is the purpose of these clocks?
> - Could someone provide me few meaningful examples (not sloppy design)
> that use multiple clocks?

How about one of our image processing designs:
3x async camera inputs (yes, it would be great to have synchronous cameras,
but it doesn't happen) @ 30MHz
1x DSP memory-mapped IO interface @ 100MHz
1x VGA frame-buffer @ 100MHz - synchronous to the DSP clock - yay!
1x VGA output @ (800x600x75)=36MHz

I had to move the cameras into the DSP clock domain, process data,
pass on to the DSP for further processing, then get "pixels to plot"
back from the DSP to put into the VGA frame-buffer.  This data was
then streamed out through a FIFO to the VGA RAMDAC.

I don't think I could have got away with less domains, but with
careful planning of the interfaces, it all worked.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Article: 105466
Subject: Re: Hardware book like "Code Complete"?
From: "radarman" <jshamlet@gmail.com>
Date: 24 Jul 2006 07:03:26 -0700
Links: << >>  << T >>  << A >>
KJ wrote:
> "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message
> news:1153510009.206861.78040@p79g2000cwp.googlegroups.com...
> > Andy wrote:
> >> Too bad the author is a proponent of the ancient style of separate
> >> clocked and combinatorial processes in VHDL. He even uses a third
> >> process for registered outputs.
> >>
> >> I think he needs to discover what variables can do for you in a clocked
> >> process.
> >
> > Really?  Which of his arguments do you disagree with?
> >
> > I always thought of the two-process style as being redundant, but after
> > reading Dr. Chu's argument, I'm revising my thinking.  For one thing,
> > this style makes it much less disruptive to change a Moore output to a
> > Mealy and vise versa.
> >
> > My thanks to S.C. for the reference.  Good one.
> >
>
> But in practice one doesn't much care if any outputs are 'Mealy' or 'Moore'.
> What one has is a function that needs to be implemented within specific area
> (or logic resource) constraints and performance (i.e. clock cycle, Tpd, Tsu,
> Tco) constraints.
>
> Breaking what can be accomplished in one process into two (or more)
> logically equivalent processes should be considered for code clarity which
> can aid in support and maintenance of the code during it's lifetime as well
> as for potential design reuse (although realistically re-use of any single
> process is probably pretty low).  Re-use happens more often at the
> entity/architecture level, but the 'copy/paste/modify' type of re-use
> probably happens more at the process level when it does happen.
>
> Breaking a process into two just to have a combinatorial process to describe
> the 'next' state and a separate process to clock that 'next' state into the
> 'current' state has no particular value when using design support and
> maintenance cost as a metric of 'value'.  Since the different methods
> produce the final end logic there is no function or performance advantage to
> either approach.  On the other hand, there are definite drawbacks to
> implementing combinatorial logic in a VHDL process.  Two of these are
> - Introduction of 'unintended' latches
> - Missing signals in the sensitivity list that result in different
> simulation versus synthesis results
>
> Both of these drawbacks have manual methods that can be used to try to
> minimize them from happening but the bottom line is that extra effort
> (a.k.a.. cost or negative value) must be incurred to do this....all of which
> is avoided by simply not using the VHDL process to implement combinatorial
> logic (i.e. the 'next' state computation).
>
> So as far as the VHDL language is concerned, there are real costs that will
> be incurred every time the two process method is used but no real value
> add....or at least that's my 2 cents.....
>
> KJ

After reading the arguments here, I have started using a mixed
approach, but I still use the two process model for state machines and
other complex logic. There are just too many times when I don't want to
wait until the next clock for an output to take affect.

At work, we have a hard requirement (as in, it won't pass a peer
review) to write in the two process model. Another hard requirement
(that I agree with) is that there should only be one clocked process
per clock. The guy that came up with the requirement predates HDL's in
general - and I'm sure there was a good reason for it at one time.

However, for my home projects, I tend to mix the one and two-process
models based on what is most convenient.

Having done so, I don't see that the two-process model is that terribly
inconvenient. I simply place a default condition at the beginning of
the process, and override the default as needed. For most processes,
this adds maybe 1-10 "extra" lines.

Perhaps it's because I was taught in the two-process model, but I find
it easier to understand what is going on when I use it, so anything
that requires me to think, I use a separate combinatorial process for.
Simple logic, like counters, pipeline registers, etc. goes into the
appropriate clocked process.

For me, this mixed approach works pretty well.


Article: 105467
Subject: Re: Why 8 clock trees in Xilinx Spartan-3 device?
From: "fp" <fpga002006@yahoo.com>
Date: 24 Jul 2006 07:22:14 -0700
Links: << >>  << T >>  << A >>
Thanks for your time, Austin.

Now I see why 3C50 has 8 clock trees.

S. C.


Austin Lesea wrote:
> Yes,
>
> It is called "simplicity."
>
> If the clock tree were to vary, it would make the assembly of each
> family member part even more of a hassle (than it already is), and the
> software would also have to be "different" for each member of the fanily
> (more than it already is).
>
> Thus, to make the resource the same for the smallest or largest part may
> be seen as a waste, yet it is the only practical way to manufacture a
> family of devices, and support them.
>
> The same is true for the routing resources:  a small part does not
> "need" all we provide, and a "large" part has perhaps too little (for
> some designs).
>
> Austin
>
> fp wrote:
>
> > Thank everyone for replies.  The info is helpful.
> >
> > There is one follow-up question for Austin.  In Spartan-3 family, most
> > hardware resource increases as the device becomes larger.  If we
> > compare 3S50 and 3S5000:
> >  - system gate: 50K vs 5M
> >  - block ram bit: 72K vs 1872K
> >  - multiplier: 4 vs 104
> >  - user I/O: 124 vs 784
> >
> > However, the number of clock tree remains the same (8) for all devices.
> > Is there a reason for this?
> >
> > Thanks in advance.
> >
> > S. C.
> >
> >
> >
> >>Austin Lesea wrote:
> >>S. C.
> >>
> >>One use I was given is that there is more than one design in the chip.
> >>Sort of like an apartment building, with different tenants.
> >>
> >>Another use is for standard interfaces which you do not get to choose
> >>the frequency:  SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78
> >>MHz, all working together to perform some overall function.
> >>
> >>Austin
> >>
> >>
> >


Article: 105468
Subject: Re: Hardware book like "Code Complete"?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 24 Jul 2006 08:12:24 -0700
Links: << >>  << T >>  << A >>
radarman wrote:
>
> After reading the arguments here, <snip> There are just too many times
> when I don't want to wait until the next clock for an output to take affect.

Stop being so impatient ;)

> Another hard requirement
> (that I agree with) is that there should only be one clocked process
> per clock. The guy that came up with the requirement predates HDL's in
> general - and I'm sure there was a good reason for it at one time.
>
This struck me as kind of odd.  I understand that if there is a hard
requirement to do it this way then you either will do it that way or
seek other employment.  I also don't find it hard to believe either
that the reason for the requirement for may predate HDLs and there was
a good reason for it at one time.

What I find odd though is that you agree with it.  Based on your other
posts to this group I could see that you could 'accept' that this is
how you have to do it but I guess I'm surprised that you would 'agree
with' something that you don't know what the reasoning is...doesn't
seem like 'radarman' talking.

By the way, if you do find the 'good' reason for having physically only
one clocked process I'd be curious to hear what it is.  Although I put
myself in the 'one process' camp my 'one process' tends to be several
physical processes all clocked by the same clock.  From a logic
synthesis/simulation perspective those multiple processes are all
logically 'one' process but breaking them up into physically separate
processes I find makes it easier to understand and debug.

KJ


Article: 105469
Subject: Re: Xilinx Virtex-4 APU Controller Questions
From: "Justin" <jfritz@swri.edu>
Date: 24 Jul 2006 08:16:39 -0700
Links: << >>  << T >>  << A >>

Ditto
I am looking at using 4 of the fpu cores provided with ISE and writing
the instruction decode and glue logic myself. This seems like a generic
enough problem that there must be an easier way. I have been having the
same problems -mhard-float does not make GCC target an FPU and the
documentation on the APU is slim. Let me know if you hear anything/
have a great breakthrough, ill do the same.


Article: 105470
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 24 Jul 2006 08:37:08 -0700
Links: << >>  << T >>  << A >>
EEngineer wrote:
> What is the ACE file size that you created? All the demos are 1686KB
> and the new ACE created with iMPACT is 1674KB.

The file that I generated was 1686KB using the 8.1.03i (Service Pack 3)
software. You can find out which version you are using the "Help -> About"
menu.

Ed

Article: 105471
Subject: Re: Hardware book like "Code Complete"?
From: "J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at) hp . com (no spaces)">
Date: Mon, 24 Jul 2006 09:27:39 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Eric wrote:
> 
> 
>>But if anyone writes a book like this it will fly off the shelves!
> 
> 
> A few hundred copies would fly off the shelves.
> 
> There's probably about 10,000 digital designers
> in the US. Not all of those do hardware description
> and not all of those write their own RTL.
> Those are not numbers that would excite
> a major publisher.

It can't justify the cost and delay of hard-copy but
could easily be sold as a pdf. Forget the idea of
publishing a single work. This should be a work
in progress that is always adding new chapters and
ideals and evolving with the industry.



> Writing and editing a book is two long years
> of work, whatever the subject.
> 
>             -- Mike Treseler


Two long man years.  Quadruple that if you have multiple
authors that need to coordinate their works and then
divide by the number of authors on the project.

Many hands make light work. Get a couple of dozen of
experienced designers, a bunch of proof reading fact
checkers and one decent editor and you  got yourself
an open source book writing project.

Put it out on sourceforge for free and make it useful for any
digital designer at any stage in their career or hobby.Do
a really good job and it can become the "bible" of the
industry that everyone has in the library.


Do we have the critical mass to pull something like this off?


Lets do a survey.  If we did a cooperative book on digital
design guidelines then what chapters would you like to see
and or contribute.


my list:


1)  Reset systems and how they work.

2)  Designing logic for scan testing (atpg)

3)  Designing bist test logic

4)  Designing and using jtag test logic

5)  Designing and using in-chip diagnostic and debugging logic





John Eaton





































Article: 105472
Subject: Re: Microblaze: how to determine remainder after integer division
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Mon, 24 Jul 2006 09:30:10 -0700
Links: << >>  << T >>  << A >>
> group).  I'm trying to write C-code (within Xilinx Platform Studio) to
> determine the remainder after an integer division.  So if I say
> 
> num = 13/10;
> rem = 13%10;
> 
> then num = 1 and rem = 3.
> 
> I'm getting an error stating "invalid operands to binary %" when I try
> to build.

You might want to check if your code compiles fine on an Intel machine. 
'%' as an operation only makes sense for integers.

> 
> What I surmise is that % is trying to convert to a binary format rather
> than obtaining the desired remainder result.  I would also assume that
> I need to include the correct header file in order to perform the
> remainder operation.

If num & rem are int's, then you don't need any headers.

> 
> However, I'm having trouble determining what math functions are
> available w/in microblaze and the associated symbols needed to perform
> desired functions (i.e., how to determine an integer remainder).
> 
> When I'm configuring microblaze in fpga hardware, should I use floating
> point?  I can't find any math include file under
> <design>/microblaze_0/include.
> 

That depends on whether you need the hardware FPU or not. The GNU 
includes are typically in $XILINX_EDK/gnu

/S

Article: 105473
Subject: Re: chipscope opb monitor
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Mon, 24 Jul 2006 09:33:02 -0700
Links: << >>  << T >>  << A >>
Check your trigger conditions. In the trigger window, apart from 
specifying the value for each trigger, you also have to mention exactly 
which trigger condition (or a boolean combination of conditions) needs 
to be enabled.

/S

Frank van Eijkelenburg wrote:
> I try to use the opb/iba unit of chipscope to monitor the opb bus within 
> a simple edk design. I took the chipscope lab example as start point. I 
> am able to see the OPB signals in chipscope, but I can not set a trigger 
> point. For example, I want to trigger at a certain address 0xFFFFXXXX. 
> If I wait for the triggercondition, the behaviour is the same if no 
> condition is set (like the immediate trigger button is clicked). Another 
> problem is: I don't see assembly or c-source code in the listing window. 
> Do I have to tell chipscope where it can find sources? What could be wrong?
> 
> In the lab example there are three control ports instantiated at the 
> ICON unit while only two ports are connected. I have two control ports 
> instantiated and connected, because ISE failed at the unconnected 
> control port (in the map phase).
> 
> Any ideas?
> Frank

Article: 105474
Subject: Xilinx Corgen & Synplicity... Anyone? Help?
From: pauljbennett@gmail.com
Date: 24 Jul 2006 09:38:22 -0700
Links: << >>  << T >>  << A >>
Hey all,

  Thanx in advance for any help.  I've got a few FIFO cores that I
created in Xilinx Core Generator.  I instantiated them in my top level
VHDL, and added the syplicity blackbox declarations after the component
declarations, as specified in the various Xilinx/Synplicity documents:

-- Synplicity black box declaration
attribute syn_black_box : boolean;
attribute syn_black_box of serial_fifo : component is true;

   I added the top level vhdl, and the Xilinx generated EDIF netlists
to my synplicity project... when I run it I get:

warning ID MT246 : Blackbox output_fifo_fifo_generator_v2_3_xst_1 is
missing a user supplied timing model.

  Now, from everything I read in the various PRF documents, the purpose
of adding the EDIF files to the synplicity project is to generate said
timing?  No?  Anyone know why synplicity is complaining here?   Thanx.




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