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
tgschwind@tiscalinet.ch wrote: > I have a design on a Spartan 3 2000. It uses nearly all slices, two > thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier > are used. > The design uses three clock. A 40 Mhz clock for configuration and > registers, 80 Mhz for data processing, and 160 Mhz for internal > processing in certain blocks. > > The problem is that the device becomes hot, so hot, that you can burn > your fingers. I measured up to 104 °C on the FPGA Ituses nearly 1.3 W. > I have alredy implemeted ClockEnables everywhere possible. Also on > RAMs. I have already sythesized with Power Reduction option. > > The Device can't have a active cooling, like a fan. > > Does anybody have some advice how to further reduce the power ? 25 % > would be great. Did you get the 104'C with an external temperature probe on the package top, or is that the calculated die temp, from measuring a thermal sense diode ? -jgArticle: 123301
On Aug 20, 2:31 pm, Peter Alfke <pe...@xilinx.com> wrote: > Frequency is not the problem. Delay differences are. A DCM is good at > aligning outgoing clock edges, down to the 100 ps level. With register > outputs you have the sum of clock delays plus clock-to-out delay. In > many applications the different clock domains have to communicate with > each other, and that can lead to ugly hold-time violations, a problem > at any, even the lowest, frequency. Under all cicumstances make sure > that the registers are driven by a common global clock, so that their > outputs are synchronous with almost identical delay. > Peter Alfke, Xilinx Applications > > On Aug 20, 11:37 am, "bwilso...@gmail.com" <bwilso...@gmail.com> > wrote: > > > How would one best judge when it is acceptable to generate a clock > > from the outputs of an internal register instead of using the standard > > blocks such as DCM's? My design will go onto an XC2V8000-5 part, and > > I'd like to use registers to generate up to a 10MHz clock if that is > > alright. Any information would certainly be appreciated. I am > > basically trying to save DCM's for the low frequency clocks if > > possible. Yeah, my chips are failing timing with huge scores and I'm seeing many nasty hold time violations. I'm driving my counters with outputs from BUFG's, so I'm not exactly sure what's going on. I originally tried a 7-DCM approach, but ran into problems because I can only have 6 of them on a single side of the die, and in one case they need to be cascaded unfortunately. Now I'm generating most of the clocks with DCM's except for 4 of them that are under 10MHz. My current design uses a total of 3 DCM's and 6 BUFG's, and I've LOC'd everything down to the bottom half of the die. I have 2 6:1 muxes implemented in normal logic in which case 4 of the inputs are clocks from DCM's and 2 are from my registers. I then run the output of the muxes to a BUFG. Any help would certainly be appreciated because I'm honestly running out of things to try. I'd be willing to share my current implementation if that would help.Article: 123302
hi all, I'm working on the ML310 board, using EDK8.2i. I'd like to know how can we write c codes that executes burst data transfer on the PLB. Can this be done directly on the PPC core or do we have to create a peripheral to do just that? Can anyone help me with this? Thanks.Article: 123303
On Aug 22, 7:48 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote: > On Aug 20, 2:31 pm, Peter Alfke <pe...@xilinx.com> wrote: > > > > > Frequency is not the problem. Delay differences are. A DCM is good at > > aligning outgoing clock edges, down to the 100 ps level. With register > > outputs you have the sum of clock delays plus clock-to-out delay. In > > many applications the different clock domains have to communicate with > > each other, and that can lead to ugly hold-time violations, a problem > > at any, even the lowest, frequency. Under all cicumstances make sure > > that the registers are driven by a common global clock, so that their > > outputs are synchronous with almost identical delay. > > Peter Alfke, Xilinx Applications > > > On Aug 20, 11:37 am, "bwilso...@gmail.com" <bwilso...@gmail.com> > > wrote: > > > > How would one best judge when it is acceptable to generate a clock > > > from the outputs of an internal register instead of using the standard > > > blocks such as DCM's? My design will go onto an XC2V8000-5 part, and > > > I'd like to use registers to generate up to a 10MHz clock if that is > > > alright. Any information would certainly be appreciated. I am > > > basically trying to save DCM's for the low frequency clocks if > > > possible. > > Yeah, my chips are failing timing with huge scores and I'm seeing many You obviously think you need all these different clocks. But it might help to be self-critical... And to what extent does the logic interact across clock boundaries? That's most likely your problem (hold-time violations). To what extent are your clocks totally asynchronous to each other, or are they just divided by integers? Peter Alfke > nasty hold time violations. I'm driving my counters with outputs from > BUFG's, so I'm not exactly sure what's going on. I originally tried a > 7-DCM approach, but ran into problems because I can only have 6 of > them on a single side of the die, and in one case they need to be > cascaded unfortunately. Now I'm generating most of the clocks with > DCM's except for 4 of them that are under 10MHz. My current design > uses a total of 3 DCM's and 6 BUFG's, and I've LOC'd everything down > to the bottom half of the die. I have 2 6:1 muxes implemented in > normal logic in which case 4 of the inputs are clocks from DCM's and 2 > are from my registers. I then run the output of the muxes to a BUFG. > Any help would certainly be appreciated because I'm honestly running > out of things to try. I'd be willing to share my current > implementation if that would help.Article: 123304
The PPC can only creat single word transactions, four-word cacheline transactions, and eight-word cacheline transactions. It cannot directly create burst transactions. - Peter lordwolf wrote: > hi all, > > I'm working on the ML310 board, using EDK8.2i. I'd like to know how > can we write c codes that executes burst data transfer on the PLB. Can > this be done directly on the PPC core or do we have to create a > peripheral to do just that? Can anyone help me with this? Thanks. >Article: 123305
hi all i am facing a problem with EDK tool. can you please assist me in this regard.the problem is :- i am using a top file of name opb.vhd, which using a INOUT signal.when i synthesis using EDK tool , a opb_wrapper file is creating by EDK tool which describes the MDIO inout signal into three signal like MDIO _O, MDIO _I , and MDIO _T .when i modifing the wrapper file as per my desire logic and synthesising it once again , it overwrites the modified wrapper file and unable to synthesis further. can u please pass the remedy. error messages are. ERROR:Xst:2585 - Port <mdio_I> of instance <opb_0> does not exist in definition <opb>. ERROR:Xst:2585 - Port <mdio_O> of instance <opb_0> does not exist in definition <opb>. ERROR:Xst:2585 - Port <mdio_T> of instance <opb_0> does not exist in definition <opb>. in summary i want to know how to handle the bidirectional signal in EDK tool.Article: 123306
Does anyone know if Spartan 3A-DSP is based of Virtex4SX, or is Virtex4SX? That might explain why the power is higher. xArticle: 123307
On Aug 22, 10:34 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 22 Aug 2007 07:45:52 -0700, witten...@googlemail.com wrote:
> >Hi,
>
> > I have a VHDL design which has no reset, within the design
> >are statements that rely on the last know state of a signal i.e sig_a
> ><= not sig_a, sig_a has not had an initial value declared in the
> >signal region, hence it's value is X, there are numerous occurrences
> >of this within the design. The design has been place and routed and
> >works ok on the board as in the real world all signals have a default
> >value. I can not change the RTL code, I therefore need to force all
> >signals in the design to a known state, I understand that force only
> >works on 1 signal at a time. Does anybody know how to force all nets,
> >or have any better ideas than using force?
>
> Most simulators have a way to inquire about what signals exist in
> a given scope. You could incorporate that into a Tcl script.
> For example, in ModelSim try loading a simulation and then issuing
> the command
>
> find signals -recursive *
>
> So here's a script that forces all signals in your toplevel
> testbench to zero:
>
> foreach sig [find signals *] {
> force $sig -deposit 0
> }
>
> Yuck.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
Another thought... you mentioned that the code works on the fpga.
Maybe you can try to simulate the gate-level netlist. Maybe the
design is not too big and a gate-level simulation not be so bad to
deal with.
Article: 123308
Hi all,
I need to implement this code (below) with a embedded processor FPGA.
Do you have any information to help me in the choice of this FPGA
(performance)
Altera // niosII,
Xilinx // microblaze
Lattice // mico32
For information, I'm trying this exemple in a Nios II (STR10 Kit) at
120MHHz,
and the time for this "for functions" is around 30 seconds...
Regards,
bhb
-----------------------------------------
my code :
double a ;
double b ;
double c ;
...
for (j = 1; j<=1000; j++)
{
for (k = 1; k<=1000; k=k+1)
{
result=k*k*a+j*b+c;
}
}
Article: 123309
Hi,
Does anybody have any luck with running the Xilinx usb-cable driver on a
Linux 64 system? I'm having severe problems with this. I have done the
steps below but have run out of ideas.
1. system is latest opensuse 10.2 with kernel 2.6.18.8-0.5 The xilinx usb
cable is detected as:
$lsusb
Bus 005 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 007 Device 001: ID 0000:0000
Bus 006 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
Bus 003 Device 002: ID 03fd:0008 Xilinx, Inc.
Bus 003 Device 001: ID 0000:0000
I tried the udev driver, compiled as 32 bits but when preloaded I get
ERROR: ld.so: object './libusb-driver.so' from LD_PRELOAD cannot be
preloaded: ignored.
Compiled as 64 bits gives the same problem.
The contents of /etc/udev/rules.d/xusbdfwu.rules is:
SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", NAME="windrvr6"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t
fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t
fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="000b", RUN+="/sbin/fxload -v -t
fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t
fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t
fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"
And I think this is correct.
f I manually run
sbin/fxload with the options above and -D /proc/bus/usb/003/002
I can see that the cable is addressed on the spartan 3A board, but
afterwards a lsusb shows:
Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 007 Device 001: ID 0000:0000
Bus 006 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 005: ID 03fd:0008 Xilinx, Inc.
Bus 003 Device 003: ID 0bda:8187 Realtek Semiconductor Corp.
Bus 003 Device 001: ID 0000:0000
Any ideas? Anybody have any luck with modifying the makefile of windrvr64
driver to get a decent 2.6.18 kerneldriver or any clue on the LD_PRELOAD
problem?
Taco
Article: 123310On Aug 23, 7:09 am, kmk1...@gmail.com wrote: > hi all > i am facing a problem with EDK tool. can you please assist me in this > regard.the problem is :- > > i am using a top file of name opb.vhd, which using a INOUT signal.when > i synthesis using EDK tool , a opb_wrapper file is creating by EDK > tool which describes the MDIO inout signal into three signal like MDIO > _O, MDIO _I , and MDIO _T .when i modifing the wrapper file as per my > desire logic and synthesising it once again , it overwrites the > modified wrapper file and unable to synthesis further. can u please > pass the remedy. > error messages are. > > ERROR:Xst:2585 - Port <mdio_I> of instance <opb_0> does not exist in > definition <opb>. > ERROR:Xst:2585 - Port <mdio_O> of instance <opb_0> does not exist in > definition <opb>. > ERROR:Xst:2585 - Port <mdio_T> of instance <opb_0> does not exist in > definition <opb>. > > in summary i want to know how to handle the bidirectional signal in > EDK tool. Did you press the "Rescan User Repositories" after messing up with the source code? Otherwise the MPD files are read from cache. If the modified MPD is rewritten by the cache file then close the EDK, modify files, delete ALL the files connected to your peripheral in project_root/implementation and then repeat the implementation. Cheers, GuruArticle: 123311
> I need to implement this code (below) with a embedded processor FPGA. > Do you have any information to help me in the choice of this FPGA > (performance) > Altera // niosII, > Xilinx // microblaze > Lattice // mico32 > For information, I'm trying this exemple in a Nios II (STR10 Kit) at > 120MHHz, > and the time for this "for functions" is around 30 seconds... MicroBlaze has h/w floating point, but I think it may only be single precision. Cheers, JonArticle: 123312
bhb wrote:
> for (j = 1; j<=1000; j++)
> {
> for (k = 1; k<=1000; k=k+1)
> {
> result=k*k*a+j*b+c;
> }
> }
You can improve the speed of this code by a factor of 1 million:
result=1000*1000*a+1000*b+c
but I assume you want to use the intermediate "result" results, too :-)
Then you should think about converting the doubles to fixed point numbers,
if possible, and implementing it in VHDL, maybe triggered from a Nios
program with a custom instruction or simply a port.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 123313On Aug 23, 5:20 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 22 Aug 2007 09:19:08 -0700, > > Andy <jonesa...@comcast.net> wrote: > >I don't suppose we need to tell you that having neither reset nor > >initializers is a bad design practice, even when it "works" in FPGA > >hardware. > > >This is one case where a two-state optimization on the simulator would > >be worth its weight in gold. > > I wonder.... I just wonder.... if anyone has created a replacement > for std_logic_1164 that has all the same names and things in it, > but rewrites the operator definitions so that 'U' gets treated > as zero.... it would simulate dog-slow because the simulator's > internal accelerations for std_logic_1164 would be bypassed, but > it would be useful in ugly situations like this. You could > even implement the operators as foreign language functions, > making it possible for them to randomize the replacement > value for 'U'... > > And no, I'm not signing-up to do it. I don't have the time, > and in any case I can't sell my soul for a second time now that > I've learnt SystemVerilog :-) > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. On Aug 23, 5:20 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 22 Aug 2007 09:19:08 -0700, > > Andy <jonesa...@comcast.net> wrote: > >I don't suppose we need to tell you that having neither reset nor > >initializers is a bad design practice, even when it "works" in FPGA > >hardware. > > >This is one case where a two-state optimization on the simulator would > >be worth its weight in gold. > > I wonder.... I just wonder.... if anyone has created a replacement > for std_logic_1164 that has all the same names and things in it, > but rewrites the operator definitions so that 'U' gets treated > as zero.... it would simulate dog-slow because the simulator's > internal accelerations for std_logic_1164 would be bypassed, but > it would be useful in ugly situations like this. You could > even implement the operators as foreign language functions, > making it possible for them to randomize the replacement > value for 'U'... > > And no, I'm not signing-up to do it. I don't have the time, > and in any case I can't sell my soul for a second time now that > I've learnt SystemVerilog :-) > -- > Jonathan Bromley, Consultant It's possible to modify std_logic_1164 as you say, it's not all that hard, just a bunch of tables. It's not what you actually should be doing, it doesn't distinguish between uninitialized state holders (registers) and uninitialized inputs. What you are actually after is getting closure between two different levels of abstraction, a behavioral model and a physical model with or without accurate timing. Being able to compare the two is the equivalent of running input stimulus for the physical model on a chip tester, a timed model where you may put delays on inputs, and may pick sample times on outputs for clock coherent comparison against the abstract model. For purposes of doing closure in say VHDL, the physical model is done using a primitives library supplied by the FPGA vendor. The generated net list model in VHDL should take care of modeling the actual intialization found in the device. If your two models don't match results you should modify the more abstract one to match initialization after determining that all the difference are significant and that you shouldn't modify how synthesis is done instead. It may be possible to ignore some output based on how long it takes for uninitialized state to clear from providing deterministic input (if possible). The comparison doesn't commence until after so long, or ignores certain output vectors or parts until visible and correct state is propagated from input stimulus. The idea is to prove the logic operates and it works for targeted timing. This creates an physical implementation dependent behavioral model, implying you should be able to modify it in an agile fashion when re- targeting the physical device. You have a good chance of finding common behavioral initialization for multiple target architectures, or you can modify the test bench (things like pull ups or pull downs on the PCB design) when you see dependencies based on availability of input buffers. Your likely to have to modify the input application times and output sample times in any event.Article: 123314
On Thu, 23 Aug 2007 04:08:27 -0700,
diogratia <diogratia@gmail.com> wrote:
>It's possible to modify std_logic_1164 as you say, it's not all that
>hard, just a bunch of tables.
Sure. The challenges are twofold: making sure that the changes
don't break existing behavioural code, and introducing power-up
randomization (see below).
>It's not what you actually should be doing,
Maybe not; I have used assorted custom multi-valued logic
arrangements in the past when I've needed to, but that's not
the point at issue here.
>What you are actually after
just to set the record straight, *I'm* not after anything at all;
the OP posed a slightly odd problem in which he's not able or
willing to modify some original source code, even though that's
what he really needs to do.
> is getting closure between two different
>levels of abstraction, a behavioral model and a physical model with or
>without accurate timing. Being able to compare the two is the
>equivalent of running input stimulus for the physical model on a chip
>tester, a timed model where you may put delays on inputs, and may
>pick sample times on outputs for clock coherent comparison against the
>abstract model.
>
>For purposes of doing closure in say VHDL, the physical model is done
>using a primitives library supplied by the FPGA vendor.
All this is true enough, but doesn't really answer the OP's (and many
others') problem: There are designs for which the power-up state of
a register is irrelevant. Modelling such power-up state as unknown
is unnecessarily and wrongly pessimistic. There is a school of
thought that argues in favour of doing 2-state simulation, with
all registers initialized to randomized 0 or 1 values. Performing
many successive simulations, with different randomized startup
values, has in some situations been shown to be better at flushing
out initialization bugs than a multi-valued logic simulation with
its excessively pessimistic treatment of initialization unknowns;
despite this, it can miss important initialization bugs for some
perfectly reasonable kinds of RTL coding style:
if (ff = '1') then -- behavioural inverter model
ff <= '0';
else
ff <= '1';
Note that this example reliably treats X, U etc as equivalent
to 0 in simulation. (A similar loophole exists in Verilog.)
Consequently, a functional bug that appears only if the FF
initializes to '1' would not be uncovered by this sim.
On the other hand, if the FF were initialised to a randomized
0/1 value, the bug could be detected in functional RTL simulation.
> The generated
>net list model in VHDL should take care of modeling the actual
>intialization found in the device.
As I suggest above, there doesn't necessarily have to be any
such real initialization. Typical gate-level models will then
continue to emit spuriously pessimistic X values. The usual
culprits are simple clock dividers, power-up timeout counters
and that sort of thing; but of course such elements can
easily bring an entire design to its knees if they go on spitting
out X values until the heat-death of the universe.
Whilst I agree with the general drift of your comments about
RTL-to-gates simulation closure, I'm very far from convinced
that it is a particularly helpful thing to do; I know ASIC
people do it a lot, and need it to flush out certain kinds
of implementation and synthesis problem, but it is not the
only act in town.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 123315On Aug 23, 6:44 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Thu, 23 Aug 2007 04:08:27 -0700, > > diogratia <diogra...@gmail.com> wrote: > >It's possible to modify std_logic_1164 as you say, it's not all that > >hard, just a bunch of tables. > > Sure. The challenges are twofold: making sure that the changes > don't break existing behavioural code, and introducing power-up > randomization (see below). > > >It's not what you actually should be doing, > > Maybe not; I have used assorted custom multi-valued logic > arrangements in the past when I've needed to, but that's not > the point at issue here. > > >What you are actually after > > just to set the record straight, *I'm* not after anything at all; > the OP posed a slightly odd problem in which he's not able or > willing to modify some original source code, even though that's > what he really needs to do. > > > is getting closure between two different > >levels of abstraction, a behavioral model and a physical model with or > >without accurate timing. Being able to compare the two is the > >equivalent of running input stimulus for the physical model on a chip > >tester, a timed model where you may put delays on inputs, and may > >pick sample times on outputs for clock coherent comparison against the > >abstract model. > > >For purposes of doing closure in say VHDL, the physical model is done > >using a primitives library supplied by the FPGA vendor. > > All this is true enough, but doesn't really answer the OP's (and many > others') problem: There are designs for which the power-up state of > a register is irrelevant. Modelling such power-up state as unknown > is unnecessarily and wrongly pessimistic. There is a school of > thought that argues in favour of doing 2-state simulation, with > all registers initialized to randomized 0 or 1 values. Performing > many successive simulations, with different randomized startup > values, has in some situations been shown to be better at flushing > out initialization bugs than a multi-valued logic simulation with > its excessively pessimistic treatment of initialization unknowns; > despite this, it can miss important initialization bugs for some > perfectly reasonable kinds of RTL coding style: > > if (ff = '1') then -- behavioural inverter model > ff <= '0'; > else > ff <= '1'; > > Note that this example reliably treats X, U etc as equivalent > to 0 in simulation. (A similar loophole exists in Verilog.) > Consequently, a functional bug that appears only if the FF > initializes to '1' would not be uncovered by this sim. > On the other hand, if the FF were initialised to a randomized > 0/1 value, the bug could be detected in functional RTL simulation. > > > The generated > >net list model in VHDL should take care of modeling the actual > >intialization found in the device. > > As I suggest above, there doesn't necessarily have to be any > such real initialization. Typical gate-level models will then > continue to emit spuriously pessimistic X values. The usual > culprits are simple clock dividers, power-up timeout counters > and that sort of thing; but of course such elements can > easily bring an entire design to its knees if they go on spitting > out X values until the heat-death of the universe. > > Whilst I agree with the general drift of your comments about > RTL-to-gates simulation closure, I'm very far from convinced > that it is a particularly helpful thing to do; I know ASIC > people do it a lot, and need it to flush out certain kinds > of implementation and synthesis problem, but it is not the > only act in town. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. While the OP has not stated it, I assume he is targeting an FPGA (this is an FPGA newsgroup). All FPGA synthesis tools (and FPGA's) I'm familiar with reliably default the initial value of all registers to '0' after configuration unless there is a reset (async or sync) to '1' in the code, or there is an explicit initialization in the declaration. Therefore, a two state logic system that by default initializes all signals to '0' would be functionally accurate for FPGA targets, tri-state logic notwithstanding. However, this does not cover the problem with asynchronous release of the "default" reset after configuration. Therefore, it is possible that the first clock after the "default" reset will result in unexpected values in multiple bit registers (i.e. counters, state machines, buses, etc.). OTOH, since multi-state logic systems (like std_logic) will not reliably emulate this behavior, there is still no associated value of a multi-state logic system over a two-state system (tri-state circuitry notwithstanding) for RTL simulations. The only way that I am aware of to reliably use the default initialization of registers in FPGAs, to the exclusion of explicit sync or async resets, is to not enable the clock until a sufficient time after the default reset has deasserted. AndyArticle: 123316
It needs to run at around 5 MHz. Yes the traces will be long about 24 inches or more. EddieArticle: 123317
Spartan 3AD is based on Spartan 3A, AustinArticle: 123318
Hi Does anyone know where I can get a copy of the gerber files for the ML365 board? cheers JonArticle: 123319
On Aug 21, 1:04 pm, Ray Andraka <r...@andraka.com> wrote: > I avoid multi-cycle constraints like the plague as well. They bring in > too many opportunities to make a mistake that will bite you later. Seems like a couple of years ago, there were some startups that were trying to create tools that would automatically/formally identify and/ or verify multi-cycle and false paths/constraints. Seemed like a really great idea. Anyone know or try one of these? I'm with Mike and Ray, I avoid such constraints if at all possible. It is just too hard to verify that you have them specified correctly, and you are not accidentally relaxing a single clock path. They are an absolute last resort for me. With enabled clock buffers, many circuits can be converted to slower clocks and automatically verified in STA with no special constraints (other than clock rates/relations). AndyArticle: 123320
On Thu, 23 Aug 2007 07:34:02 -0700, "Eddie H" <> wrote: >It needs to run at around 5 MHz. Yes the traces will be long about 24 inches or more. > >Eddie Then to make it really clean, put the resistors near the FPGA and make R1 || R2 equal to the trace impedance, which will source-terminate the line. I don't know which cml parts you're using, so check my math as regards levels. JohnArticle: 123321
On Aug 23, 3:34 am, Frank Buss <f...@frank-buss.de> wrote:
> bhb wrote:
> > for (j = 1; j<=1000; j++)
> > {
> > for (k = 1; k<=1000; k=k+1)
> > {
> > result=k*k*a+j*b+c;
> > }
> > }
>
> You can improve the speed of this code by a factor of 1 million:
>
> result=1000*1000*a+1000*b+c
Yes, you can, but your reduction of the sum of sum it is not
correct ...
Try again :-)
--
mmihai
Article: 123322
Hello,
Regardless, I got this error while synthesizing a Verilog project. The
problem was that I adopted a project from ISE 7.1.04. After starting a
fresh project on ISE 9.2, handpicking the HDL files and UCFs (and so
on) the synthesis went smoothly.
Maybe this will do the trick for you too.
Eli
Article: 123323I think the FishTail product does this. ---Matthew Hicks > On Aug 21, 1:04 pm, Ray Andraka <r...@andraka.com> wrote: > >> I avoid multi-cycle constraints like the plague as well. They bring >> in too many opportunities to make a mistake that will bite you later. >> > Seems like a couple of years ago, there were some startups that were > trying to create tools that would automatically/formally identify and/ > or verify multi-cycle and false paths/constraints. Seemed like a > really great idea. Anyone know or try one of these? > > I'm with Mike and Ray, I avoid such constraints if at all possible. It > is just too hard to verify that you have them specified correctly, and > you are not accidentally relaxing a single clock path. They are an > absolute last resort for me. With enabled clock buffers, many circuits > can be converted to slower clocks and automatically verified in STA > with no special constraints (other than clock rates/relations). > > Andy >Article: 123324
On Thu, 23 Aug 2007 17:27:23 +0000 (UTC), Matthew Hicks <mdhicks2@uiuc.edu> wrote: >I think the FishTail product does this. It uses formal analysis techniques to locate multi-cycle paths and check the validity of your multi-cycle constraints. BluePearl's tool does somewhat similar things. I suspect that both are likely to be priced out of reach of typical FPGA users, though. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
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