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 118075

Article: 118075
Subject: Re: Spartan 3E Not enough block ram.
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Tue, 17 Apr 2007 08:07:14 -0400
Links: << >>  << T >>  << A >>
Ken Soon wrote:
> Hmm why in this case the
>       dout1 <= dout2;
>       dout  <= dout1;
> is being placed outside the enable block then? Because I do not want any
> latency when retrieving data?
> I hope this does not add on any timing delay, if not I could be keeping on
> adding register level in vain.

Each added register will add a latency cycle, what you need to do is make 
sure that all the data comes together with matched latencies. I put the 
extra dout registers outside any ifs because the extra control logic for 
bringing the clock/read-enable further down would not have any net effect.

> And really thanks alot for the code, it was spot on. I guess I could never
> figured the part about the address and enable needing to be delayed myself.
 > Hmm come to think of it, it looks kind of stupid to do reassignment of
 > signals in the same block.

If you continue to work with FPGAs and relatively high-speed designs, you 
will find that it is often a fundamental necessity.

> From there on, I found out that I need to select register balancing => Yes
> in synthesis option.
> After doing so, the timing code really dropped by more significant amounts.

Balancing and the other related options are necessary to let XST move 
registers around when you want to use "automatic pipelining". Unless some 
of these options are enabled, extra registers get synthesized as plain 
extra registers that do nothing more than delay data. Since each extra 
register optimization option gives XST more freedom in redistributing FFs, 
synthesis will be slower.

> Oh btw I have then tried to add on more register levels.
> Have tried some structures, and I deduce this coding should be logical.
> Wonder if there is anything wrong. The lowest I have brought the timing down
> is a slack of about 1ns

There are limits to how many registers XST is able to move around when 
using automatic pipelining and it appears to vary from two to four 
depending on constructs and tool versions.

Article: 118076
Subject: No Synplify evaluation?
From: Richard Klingler
Date: Tue, 17 Apr 2007 14:31:18 +0200
Links: << >>  << T >>  << A >>
Good afternoon..

Has anyone being lucky in the past getting a Synplify for Linux
evaluation license?

Mentor has some online feedback form to request an evaluation
license, but apparently their eimail goes always to /dev/null (o;


I received the ispLever for Linux including license from Lattice
directly but as you know the more expensive software lacks
any synthesizing tools...

I know I could switch to Windows..but..I already have it...
(thanx again to Lattice Semiconductor for their great support
sponsoring me software/hardware ;o)

I just need the Linux version for porting several software
to the Linux platform....


cheers
rick



Article: 118077
Subject: Re: Safety of bidirectional lines
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Tue, 17 Apr 2007 08:38:54 -0400
Links: << >>  << T >>  << A >>
Sebastien Bourdeauducq wrote:
> Ok, thanks :)
> 
> But why is slew rate related to resistance to short-circuits ?

What is slew rate? It is how fast a signal goes from one voltage to another.

What limits slew rate? Mostly path impedance, capacitance and driver strength.

IOBs use current-limited output drivers for slow slew while fast-mode 
current is only limited by the output drivers MOS' impedance... over 100mA 
per pin - a few shorts to ground with those and you can burn out the Vccio 
bonding wires/traces, assuming the output drivers can survive a sustained 
short at this power level (150-400mW each) in the first place.

Article: 118078
Subject: Re: PLB Master
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 17 Apr 2007 08:46:21 -0400
Links: << >>  << T >>  << A >>
HDL simulation only.  Just simulated the pieces of the interface and it 
worked when it was implemented in a V2P20


Jeff Cunningham wrote:
> Eli Hughes wrote:
>> I had to implement a PLB master the other year for a project.  To be 
>> honest, it is actually easier if you just get the core connect spec 
>> and write it your self.
>>
>> In my case, I was only doing 64-bit transfers.  The logic was actually 
>> pretty simple.  I spent a week with the IPIF and it never really 
>> worked right.   I told a co-worker that I did not think they ever 
>> tested the IPIF master operation.
>>
>> My own implementation only took a day or 2.  Believe it or not the 
>> state machine to do is pretty small.
> 
> Eli,
> Just curious, did you debug it with HDL simulation or chipscope?

Article: 118079
Subject: Re: Safety of bidirectional lines
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 17 Apr 2007 13:46:55 +0100
Links: << >>  << T >>  << A >>
"Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote in message 
news:Ic3Vh.17620$iq5.533929@wagner.videotron.net...
>
> IOBs use current-limited output drivers for slow slew
Hi Daniel,
Can you point me to a reference for this statement?
Thanks, Syms. 



Article: 118080
Subject: Re: par [placer] consistency
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 17 Apr 2007 13:48:38 +0100
Links: << >>  << T >>  << A >>
On 16 Apr 2007 15:00:55 -0700, "mmihai" <iiahim@yahoo.com> wrote:

>On Apr 16, 1:39 pm, "mmihai" <iia...@yahoo.com> wrote:
>
>> [...]
>>   Requirement:          10.000ns
>>   Data Path Delay:      10.679ns (Levels of Logic = 4)

>Inspired by a recent thread in this newsgroup (look for  "Xilinx ISE
>9.1 subject") I've tried "par" with different (default is 1)  "cost
>table" values (-t option) and it seems this option helps in meeting
>the target timing. With "-t 2" I'm getting:
>
>Timing summary:
>---------------
>
>Timing errors: 0  Score: 0
>
It's quite normal to get timing variations of a few percent from 
(a) extremely minor changes to the design and 
(b) changes to the "cost table" setting (or random seed).

If I fail to meet timings by less than 10%, one option is to run MPPR
overnight, to place/route with 10 or more different seeds - usually at
least one makes it through timings. Failing that, if I don't want to
modify the design, I look at the best failing pass in FPGA Editor, and
often the problem is only a few absurdly badly placed components, which
I can unroute, move, then let reentrant routing take over.

As I understand it, the placer places components apparently randomly,
then evaluates the "cost" i.e. difficulty of routing, according to a
number of factors, placing a (slightly arbitrary) cost weighting on
things like distance between related components, and congestion. Then it
repeatedly rearranges components to reduce that cost. 

The slightest design change can completely change the start position, so
this procedure can fail to find the same "minimum cost" from the same
weighting factors. But a different set of weighting factors may produce
a better minimum from the new start.

What's missing in the PAR process is feedback from a failed routing pass
about specific placement problems, back into the placer, to allow it to
re-place those components, and try again.

- Brian

Article: 118081
Subject: Re: FPGA High speed Transceivers for source synchronus bus
From: Test01 <cpandya@yahoo.com>
Date: Tue, 17 Apr 2007 05:53:33 -0700
Links: << >>  << T >>  << A >>
Thanks for your feedback.

Yes. My data rate requirement is much higher 6.4 Gbps per channel and I have 20 channel that need to run synchronously. The issue with XAPP265 is the it will require a lot of external componets 8:1 serializer and 1:8 deserializer along with 3.2/6.4 GHz clock alignment challenges. But all this is integrated inside the transceivers. This is why I am curious if we can leverage the FPGA transcievers for this application. For data alignment we may be able to use a precise delay element in line with the high speed tranceivers.

What issues do you see in using the Transceivers?

I really appreciate your feedback.

Article: 118082
Subject: Re: plb_tft_cntlr_ref for an ML405 EDK Project
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Tue, 17 Apr 2007 13:54:58 +0100
Links: << >>  << T >>  << A >>
Ben Jones wrote:
> "Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in 
> message news:f01v8b$r5q$1@dux.dundee.ac.uk...
>> I am working with an ML405 and trying to put together a project of my own 
>> that uses the plb_tft_cntlr_ref IP from the example project.  I tried to 
>> import the IP using the "Create or Import Peripheral" wizard but it 
>> complains that there are a bunch of signals missing that are needed by the 
>> PLB.
> 
> You don't need to do that. All you need to do is drop the plb_tft_cntlr_ref 
> pcore into the "pcores" directory in your project. Then (once you've closed 
> and re-opened the project so XPS re-reads the directory) you'll see it in 
> the peripheral repository and you can just add it to the project like any 
> other piece of IP in the library.

Ben,

Thanks for your response.  I tried what you suggested, which got me a 
fair way but when I went to connect my shiny new IP up (under the 
"ports" display mode) things got a bit funny.  In the example project 
there are two signals (SYS_plbClk and SYS_dcrClk) which don't appear in 
the ports display in my project.  Despite this, I bashed on and 
connected up the external signals then added some lines to the UCF to 
match.  When I attempt to generate the netlist it says:

Performing Clock DRCs...

This application has discovered an exceptional condition from which it 
cannot recover.
make: *** [implementation/ppc405_0_wrapper.ngc] Error 1

That's not a good thing, right? ;)  Any ideas?

Thanks in advance,
-- Peter

Article: 118083
Subject: Re: Safety of bidirectional lines
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 17 Apr 2007 14:00:18 +0100
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:4624c226_3@x-privat.org...
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote in message 
> news:Ic3Vh.17620$iq5.533929@wagner.videotron.net...
>>
>> IOBs use current-limited output drivers for slow slew
> Hi Daniel,
> Can you point me to a reference for this statement?
> Thanks, Syms.
>
Also, you might be interested in this.
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/1a44fd002e26bf87/ca0581ab55b1f113?lnk=st&q=slow+slew+transistor+site%3Axilinx.com&rnum=2&hl=en#ca0581ab55b1f113
It seems the slew rate is determined, as I suspected, by controlling the 
slew rate at the gate of the drive transistor. The gate has significant 
capacitance, so adjusting how hard you drive the gate will adjust the output 
slew rate. I think saying the slew rate depends on 'current-limiting' is a 
little misleading. I reckon, EMI aside, changing the slew rate setting will 
have bugger all effect on the OP's system when it's in contention, assuming 
the contention lasts for more than few ns.
HTH, Syms. 



Article: 118084
Subject: Re: par [placer] consistency
From: Gabor <gabor@alacron.com>
Date: 17 Apr 2007 06:03:22 -0700
Links: << >>  << T >>  << A >>
On Apr 17, 7:48 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On 16 Apr 2007 15:00:55 -0700, "mmihai" <iia...@yahoo.com> wrote:
>
> >On Apr 16, 1:39 pm, "mmihai" <iia...@yahoo.com> wrote:
>
> >> [...]
> >>   Requirement:          10.000ns
> >>   Data Path Delay:      10.679ns (Levels of Logic = 4)
> >Inspired by a recent thread in this newsgroup (look for  "Xilinx ISE
> >9.1 subject") I've tried "par" with different (default is 1)  "cost
> >table" values (-t option) and it seems this option helps in meeting
> >the target timing. With "-t 2" I'm getting:
>
> >Timing summary:
> >---------------
>
> >Timing errors: 0  Score: 0
>
> It's quite normal to get timing variations of a few percent from
> (a) extremely minor changes to the design and
> (b) changes to the "cost table" setting (or random seed).
>
> If I fail to meet timings by less than 10%, one option is to run MPPR
> overnight, to place/route with 10 or more different seeds - usually at
> least one makes it through timings. Failing that, if I don't want to
> modify the design, I look at the best failing pass in FPGA Editor, and
> often the problem is only a few absurdly badly placed components, which
> I can unroute, move, then let reentrant routing take over.
>
> As I understand it, the placer places components apparently randomly,
> then evaluates the "cost" i.e. difficulty of routing, according to a
> number of factors, placing a (slightly arbitrary) cost weighting on
> things like distance between related components, and congestion. Then it
> repeatedly rearranges components to reduce that cost.
>
> The slightest design change can completely change the start position, so
> this procedure can fail to find the same "minimum cost" from the same
> weighting factors. But a different set of weighting factors may produce
> a better minimum from the new start.
>
> What's missing in the PAR process is feedback from a failed routing pass
> about specific placement problems, back into the placer, to allow it to
> re-place those components, and try again.
>
> - Brian


You can make up for the lack of feedback in the MPPR by doing a little
manual component placement.  In your case it is likely that the block
RAMs are in the critical timing paths.  If you take the location of
the
placed block RAMs from a successful PAR (one that meets timing)
and add them as LOC constraints in your .ucf file (or in the source
code if they are instantiated), you'll probably find that the
place&route
process will go better.

HTH,
Gabor


Article: 118085
Subject: Re: PLB Master
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 17 Apr 2007 09:03:49 -0400
Links: << >>  << T >>  << A >>
I am not permitted to share my code BUT here is what I did:

My master operation was driven by a couple of IPIF slave registers.  I 
had the tool generate a generic IPIF slave interface (one with just a 
few registers).

I use Verilog ---> I then added these signals to the port declaration 
list in userlogic.v (don't forget to hook these up in main VHDL file!):

		PLB_Clk,
		PLB_Rst,
		M_abort,
		M_ABus,
		M_BE,
		M_busLock,
		M_compress,
		M_guarded,
		M_lockErr,
		M_ordered,
		M_priority,
		M_request,
		M_RNW,
		M_size,
		M_type,
		M_wrBurst,
		M_wrDBus,
		PLB_MErr,
		PLB_MWrDAck,
		PLB_MAddrAck,


Note that Xilinx uses  the same net names as in the PLB core connect spec

input                                    PLB_Clk;
input                                    PLB_Rst;
output                                   M_abort;
output   [0:C_PLB_AWIDTH-1]              M_ABus;
output   [0:C_PLB_DWIDTH/8-1]            M_BE;
output                                   M_busLock;
output                                   M_compress;
output                                   M_guarded;
output                                   M_lockErr;
output                                   M_ordered;
output   [0:1]                           M_priority;
output                                   M_request;
output                                   M_RNW;
output   [0:3]                           M_size;
output   [0:2]                           M_type;
output                                   M_wrBurst;
output   [0:C_PLB_DWIDTH-1]              M_wrDBus;

input                                    PLB_MErr;
input                                    PLB_MWrDAck;
input                                    PLB_MAddrAck;



For my application, my PLB master always wrote to memory,  Most of the 
PLB signals could be fixed.  I was always doing PLB writes (64-bit) so:

assign M_priority = 2'b11;		// Keep this transaction priority high
assign M_busLock = 0;
assign M_abort = 0;
assign M_RNW = 0;
assign M_BE = 8'b11111111;			//We are send all 64-bits
assign M_size = 4'b0;
assign M_type = 3'b000;			   //memory transfer
assign M_compress  = 0;
assign M_guarded = 0;
assign M_ordered = 0;


I drove the Address and write data buses with my own logic.....

assign M_ABus = EffectiveTransferAddress;
assign M_wrDBus[0:31] = TransferCount;
assign M_wrDBus[32:63] = ~TransferCount;


Now, when you have a PLB bus in a EDK project, a PLB arbiter is added 
for you.  This is something that is needed whether you use IPIF or not.

Now, the only thig you have to do is have a state machine to operate 
these PLB signals:

PLB_MErr
M_request
PLB_MAddrAck
PLB_MWrDAck


These are used to talk to the arbiter and request access.  These signals 
are for writing only!  If you are doing reading you need some addition 
PLB signals.


Look in the spec to implement you state machine.


Hope this helps!  It is also important that you make your first example 
very simple. My first implementation was logic that will fill up some 
RAM on the PLB bus with a number sequence.  I could then look in RAM to 
make sure the master was working.....

This may seem like a really difficult piece of logic but its not as bad 
as you would think.  Just read the PLB spec and you'll be fine.

Good Luck!


LilacSkin wrote:
> To build my PLB master, I only need that ports ???
> 
> 
> PLB Master n Interface
> 
> PLB-to-Master N
> 
> PLB_MnWrDAck
> PLB_MnRdAck
> PLB_MnAddrAck
> PLB_MnRearbitrate
> PLB_MnTimeout
> 
> Master n-to-PLB
> 
> Mn_request
> Mn_priority(0:1)
> Mn_RNW
> Mn_size(0:3)
> Mn_rdBurst
> Mn_abort
> Mn_wrBurst
> Mn_ABus(0:31)
> Mn_UABus(0:31)
> 
> 
> PLB Slave n Interfaces
> 
> PLB-to-slave n
> 
> PLB_RNW
> PLB_abort
> PLB_wrBurst
> PLB_rdBurst
> PLB_masterID(0:2)
> PLB_PAValid
> PLB_SAValid
> PLB_ABus(0:31)
> PLB_UABus(0:31)
> 
> Slave n-to-PLB PLB
> 
> Sln_wait
> Sln_AddrAck
> Sln_rearbitrate
> Sln_rdComp
> Sln_rdDAck
> Sln_wrComp
> Sln_wrDAck
> 
> Where are the ports in the IBM datasheet ?
> 
> PLB_pendpri
> PLB_penreq
> PLB_reqpri
> PLB_size
> PLB_type
> PLB_rdPrim
> PLB_abort
> PLB_buslocked
> PLB_masterID
> PLB_MSize
> PLB_compress
> PLB_guarded
> PLB_lockerrr
> PLB_MErr,
> PLB_MBusy.......
> 

Article: 118086
Subject: Re: type/subtype definition in entity
From: Andy <jonesandy@comcast.net>
Date: 17 Apr 2007 06:09:42 -0700
Links: << >>  << T >>  << A >>
Right now, there isn't a good way to handle what you want, exactly. As
Alan said, Accellera's 2006 std has the ability to invoke packages
with generics, which would do what you want.

For now, I would do one of two things:

First, the package for this entity could use a constant from another
package (a higher level project package) to get the sizes. BTW,
whenever I create packages that have typedefs, etc for an entity, I
them at the top of the same file that has the entity/arch in it. That
way, if you've compiled the entity/arch, you've also compiled the
package necessary to use it. I also often define a record type to hold
all the generics for the entity in that package. That way handling all
the generics up through the hierarchy gets easier. Higher level
packages for higher level entities reference the lower level entities'
packages' generic record definitions, and so on, all the way to the
top. So adding a new parameter for a lower level entity means adding
it only to the entity/arch/package that needs it, and to the top level
where it gets set. It gets automatically plumbed through all the
levels in between.

The second method would be to pack the entire array into one long SLV
(can be an unconstrained port). Then you can pass generics into the
entity that allow you to recompose the array from the SLV (or
decompose the array to drive the port). Not the prettiest solution,
but it works.

Hope this helps,

Andy

On Apr 17, 4:46 am, Alan Fitch <alan.fi...@spamtrap.com> wrote:
> zhang...@gmail.com wrote:
> > I want to define a type related to entity generics, like an array in
> > the following codes. But It seems I have no places to put those
> > subtype/type statements in the entity. I can not use package to define
> > those subtype/type since there are related to entity generics.
>
> > Any solution or idea?
>
> > Thanks a lot,
>
> > Z
> > 04/16/07
>
> > ===============
> > library IEEE;
> > use IEEE.std_logic_1164.all;
> > use IEEE.std_logic_arith.all;
> > use IEEE.std_logic_unsigned.all;
>
> > entity ir is
> > --   Here is not correct
> > --   subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0);
> > --   type    MY_UNSIGNED_VECTOR is array(natural range<>) of
> > MY_UNSIGNED;
> >    generic (
> >       EL_SIZE  : POSITIVE := 16;
> >       EL_COUNT : POSITIVE := 8
> >    );
> > --   Here is not correct either
> > --   subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0);
> > --   type    MY_UNSIGNED_VECTOR is array(natural range<>) of
> > MY_UNSIGNED;
> >    port (
> >       val_b : out MY_UNSIGNED_VECTOR (0 to EL_COUNT-1);
> >       clk_i : in std_logic
> >       ...
> >    );
> > end ir;
>
> Hi Z,
>
>    you must put the declarations in a package, e.g.
>
> library ieee;
> use ieee.std_logic_arith.all; -- prefer numeric_std, it's a standard
>   package mytypes is
>       subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0);
>       type    MY_UNSIGNED_VECTOR is array(natural range<>) of MY_UNSIGNED;
>
>    end package mytypes;
>
> Of course you then don't have access to the generic. So you need to
> fix the generic size using a constant or the subtype itself, e.g.
>
>   package mytypes is
>       constant EL_SIZE : positive := 10;
>       subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0);
>       type    MY_UNSIGNED_VECTOR is array(natural range<>) of MY_UNSIGNED;
>
>    end package mytypes;
>
> You must make the package visible in front of the entity of course, e.g.
>
> library mylib;
> use mylib.mytypes.all;
> library ieee;
> ...
>
> entity...
>
> assuming you compiled the package into library 'mytypes'
>
> Does that help?
>
> In Accellera VHDL2006 you can have package generics, which would be a
> neater solution - but your tools must have 2006 support.
>
> regards
> Alan
>
> --
> Alan Fitch
> Douloshttp://www.doulos.com



Article: 118087
Subject: Re: plb_tft_cntlr_ref for an ML405 EDK Project
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Tue, 17 Apr 2007 14:12:45 +0100
Links: << >>  << T >>  << A >>
Hi Peter,

"Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in 
message news:f02g32$9da$1@dux.dundee.ac.uk...

>>> I am working with an ML405 and trying to put together a project of my 
>>> own that uses the plb_tft_cntlr_ref IP from the example project.

>> All you need to do is drop the plb_tft_cntlr_ref pcore into the "pcores" 
>> directory in your project.

> Thanks for your response.  I tried what you suggested, which got me a fair 
> way but when I went to connect my shiny new IP up (under the "ports" 
> display mode) things got a bit funny.  In the example project there are 
> two signals (SYS_plbClk and SYS_dcrClk) which don't appear in the ports 
> display in my project.  Despite this, I bashed on and connected up the 
> external signals then added some lines to the UCF to match.  When I 
> attempt to generate the netlist it says:
>
> Performing Clock DRCs...
>
> This application has discovered an exceptional condition from which it 
> cannot recover.
> make: *** [implementation/ppc405_0_wrapper.ngc] Error 1
>
> That's not a good thing, right? ;)

Depends how much you like error messages I suppose :-)

The SYS_plbClk port on the TFT reference design needs to be connected to the 
same clock as the PLB bus (which is often called sys_clk_s if you're using a 
design that originated with Base System Builder). The SYS_dcrClk similarly 
needs to be connected to the clock signal of the DCR bus. Neither of these 
clocks should need to come from an external pin. In fact I have a feeling 
that the DCR clock isn't even really a clock in the true sense of the word.

In the reference design project I saw, the DCR bus connection on the TFT 
block was connected to the PowerPC processor by means of an OPB-to-DCR 
bridge, for some obscure reason. You can do that, or you can hook it up to 
the PowerPC's DCR master port directly. The only difference is the action 
the software has to perform when accessing the TFT's control registers, 
which you only need to do if you want to (a) turn the thing on and off or 
(b) change the base address of the frame buffer dynamically.

Good luck,

      -Ben- 



Article: 118088
Subject: Re: Interfacing FPGA with TTL
From: Dave Pollum <vze24h5m@verizon.net>
Date: 17 Apr 2007 06:17:41 -0700
Links: << >>  << T >>  << A >>
On Apr 17, 3:07 am, "Jalen....@gmail.com" <Jalen....@gmail.com> wrote:
> Hi,
>
> I am using the UP2 development board from Altera. I have programmed a
> simple ALU in it. I have done some hardware tests on it through its
> expansion slots but the results are inconsistent. To perform the
> tests, I connect the expansion slots with IDE cables to a verabod in
> which i have soldered many switches and LEDs. However the results were
> inconsistent, sometimes I couldn't load the the values into the bus at
> load at all. Other times when i load the upper bits, the lower bits
> get erased. Any inputs on this? I was also thinking of interfacing it
> with a control card made entirely of TTL chips. Power source is taken
> from the TTL control card. Any inputs on the potential problems I
> might face? Thanks!
>
> Jalen


I'm not familiar with Altera parts or your UP2, so this is all I could
think of...Make sure that all of the inputs to the Altera PLD chips
are connected to a HI or LO voltage.  Floating inputs can cause a CMOS
chip to do wierd things.  If the TTL board is sending a clock to the
UP2, keep the IDE cable as short as you can.  Also, on the TTL board,
make sure that you have plenty of bypass caps (a 0.1uF cap per chip is
OK).
HTH
-Dave Pollum


Article: 118089
Subject: Re: Why 166Mhz DDR?
From: rohit2000s@yahoo.com
Date: 17 Apr 2007 06:24:02 -0700
Links: << >>  << T >>  << A >>
On Apr 16, 11:23 pm, "Daniel S."
<digitalmastrmind_no_s...@hotmail.com> wrote:
> ghel...@lycos.com wrote:
> > On Apr 15, 12:33 pm, rohit20...@yahoo.com wrote:
> >> Hi,
>
> >> I was wondering how the number 166Mhz for DDR came up? Why not say...
> >> 200MHz/250MHz DDR? I am sure there is some thought process behind
> >> that, could someone help me walk through?
>
> > Perhaps this number is how slow one can go, not how fast?  If you're
> > not meeting timing with your FPGA, the low frequency number could be
> > important.
>
> > DDR does have a minimum frequency...
>
> The minimum operating frequency for DDR DRAMs comes from the DLL circuitry
> used to capture data. My 166MHz Infineon DRAMs say the minimum operating
> frequency for its DLL is 100MHz.
>
> The maximum operating frequency is determined by how fast the DRAM is able
> to get data into or out of the active row (data) register and other control
> structures with the maximum amount of pipelining enabled. Since the high-K
> process used for DRAMs yields slow logic, latency cycles (intermediate
> registers) pile up really fast on high-speed DRAMs.

Thanks Ben & Daniel ! I think you answered my curiosity question :)

-Uday



Article: 118090
Subject: 80000 Bit Shift Register
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 17 Apr 2007 09:52:48 -0400
Links: << >>  << T >>  << A >>

I am implementing an 80000 Element Shift register to be used as a very 
long (1Sec) digital delay generator. (Yes, its that big).     It is 
clocked at 80kHz.

Its a very simple design, just an ordinary shifter register with 80k 
elements. It is being implemented in a V2Pro (Digilent XUP Board).

I have simulated the design and it works OK.  I am now trying to 
synthesize the design and it is taking a *VERY* long time.  I tried to 
synthesize on my PC (P4 3.2GHz, 1G Ram) when I left work last night.  It 
failed 5 hours later with an out of memory error.  I am now trying on a 
Xeon Work station with 3GB of RAM.

Any pointers on how to make this synthesize faster?

What kind of machines are people using out there to synthesize large 
designs?


Article: 118091
Subject: Re: plb_tft_cntlr_ref for an ML405 EDK Project
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Tue, 17 Apr 2007 14:55:45 +0100
Links: << >>  << T >>  << A >>
Ben Jones wrote:
> Peter Mendham wrote:
>>>> I am working with an ML405 and trying to put together a project of my 
>>>> own that uses the plb_tft_cntlr_ref IP from the example project.
>>> All you need to do is drop the plb_tft_cntlr_ref pcore into the "pcores" 
>>> directory in your project.
>> In the example project there are two signals (SYS_plbClk and SYS_dcrClk) 
>> which don't appear in the ports display in my project.
>> ...  When I attempt to generate the netlist it says:
>>
>> Performing Clock DRCs...
>> This application has discovered an exceptional condition from which it 
>> cannot recover.
>>
> The SYS_plbClk port on the TFT reference design needs to be connected to the 
> same clock as the PLB bus ... The SYS_dcrClk similarly
> needs to be connected to the clock signal of the DCR bus.

I was wondering whether the non-appearance of these ports in my project 
was something to with the unexplained nasty error.  Since these have 
never appeared under ports, I've never connected them up.  This is a 
naive guess based on the fact that the error occurred whilst doing 
something to do with clocks.  What do you think?  A red herring?  Is 
there any way to persuade the "ports" display to show these so that I 
know they're connected to the correct clock?

> In the reference design project I saw, the DCR bus connection on the TFT 
> block was connected to the PowerPC processor by means of an OPB-to-DCR 
> bridge, for some obscure reason. You can do that, or you can hook it up to 
> the PowerPC's DCR master port directly.

I've duplicated the reference design for now with the whole OPB/DCR 
bridge thing. It's good to know that you can hook up the DCR directly. 
I'll try that if/when I ever get the thing working.

> Good luck,

Thanks :|

-- Peter

Article: 118092
Subject: 80000 Bit Shift Register - The Code
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 17 Apr 2007 09:57:38 -0400
Links: << >>  << T >>  << A >>
Eli Hughes wrote:
> 
> I am implementing an 80000 Element Shift register to be used as a very 
> long (1Sec) digital delay generator. (Yes, its that big).     It is 
> clocked at 80kHz.
> 
> Its a very simple design, just an ordinary shifter register with 80k 
> elements. It is being implemented in a V2Pro (Digilent XUP Board).
> 
> I have simulated the design and it works OK.  I am now trying to 
> synthesize the design and it is taking a *VERY* long time.  I tried to 
> synthesize on my PC (P4 3.2GHz, 1G Ram) when I left work last night.  It 
> failed 5 hours later with an out of memory error.  I am now trying on a 
> Xeon Work station with 3GB of RAM.
> 
> Any pointers on how to make this synthesize faster?
> 
> What kind of machines are people using out there to synthesize large 
> designs?
> 


Here is my Code:

module shift(Clk, SIn, SOut);
     input Clk;
     input SIn;
     output SOut;


reg [80000:0] MyShift;
reg Out;

initial
begin
	MyShift = 0;
	Out=0;
end

assign SOut = Out;

always @(posedge Clk)
begin
	MyShift <= MyShift<<1;
	MyShift[0] <= SIn;
	//This is Needed to make XST happy and not reduce the design to
	//a GND net
	Out <= MyShift[80000];
end

endmodule





Article: 118093
Subject: Re: 80000 Bit Shift Register
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 17 Apr 2007 15:02:57 +0100
Links: << >>  << T >>  << A >>
"Eli Hughes" <emh203@psu.edu> wrote in message 
news:f02jfc$nfi$1@f04n12.cac.psu.edu...
>
> I am implementing an 80000 Element Shift register to be used as a very 
> long (1Sec) digital delay generator. (Yes, its that big).     It is 
> clocked at 80kHz.
>
> Its a very simple design, just an ordinary shifter register with 80k 
> elements. It is being implemented in a V2Pro (Digilent XUP Board).
>
> I have simulated the design and it works OK.  I am now trying to 
> synthesize the design and it is taking a *VERY* long time.  I tried to 
> synthesize on my PC (P4 3.2GHz, 1G Ram) when I left work last night.  It 
> failed 5 hours later with an out of memory error.  I am now trying on a 
> Xeon Work station with 3GB of RAM.
>
> Any pointers on how to make this synthesize faster?
>
> What kind of machines are people using out there to synthesize large 
> designs?
>
At 80 kHz, it would be easy to make a shift register out of the BRAMs if you 
aren't interested in the intermediate results. i.e. a FIFO. Each BRAM has 
18kbits. Search the Xilinx website for FIFO to see how to implement this.
HTH, Syms. 



Article: 118094
Subject: Re: 80000 Bit Shift Register
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 17 Apr 2007 16:05:54 +0200
Links: << >>  << T >>  << A >>
Eli Hughes wrote:

> Any pointers on how to make this synthesize faster?

What about using block ram and just an index pointer? Shift-in: set current
bit at index, increment index pointer, read current bit and shift it out.
If the index pointer reaches some limit, reset it to 0. If you clock the
FPGA with a higher frequency, then the read/write cycles are no problem
with your shift clock.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 118095
Subject: Re: xilinx unused I/O state
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 17 Apr 2007 15:07:09 +0100
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:4624ad7e_3@x-privat.org...
> "Steve" <eejju@polyu.edu.hk> wrote in message 
> news:1176808198.147633@nsserver1.polyu.edu.hk...
>> Hi,
>>
>> What is the default state of the unused I/O pins for Xilinx FPGA (Spartan 
>> 3E)? For Altera FPGA, it can be set as input tri-stated or as output 
>> driving gnd, etc. Is there any counterpart operation in Xilinx  ISE to 
>> set the unused I/O pins?
>>
>> Thanks,
>> JJ
>>
> Google this.
> unused I/O pins site:xilinx.com
>
> HTH, Syms.
And a little bit more helpfully, in the P&R tools under 'Generate 
Programming File' there an option called Unused IOB pins. You can set it to 
Pull Up, Pull Down or Float.
HTH, Syms. 



Article: 118096
Subject: Re: vpw/pwm controller
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Tue, 17 Apr 2007 15:09:59 +0100
Links: << >>  << T >>  << A >>
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes:

> On 16 Apr 2007 01:56:48 -0700, 
> ashasravanthi@gmail.com wrote:
>
>>hi all,
>>        can anyone tell me where i can get a free vpw/pwm controller
>>either in vhdl or verilog according to j1850 standards.
>
> Sounds like we don't know what "j1850" is.  Could you point 
> us at a reference somewhere?
>

J1850 is an automotive comms bus, a bit like CAN, but (usuallY) only
with one wire and a simple physical layer (single pull-up transistor
per node):
http://www.interfacebus.com/Automotive_SAE_J1850_Bus.html

I guess the OP wants to do access the engine diagnostics.

To my mind this is much more of a microcontroller task than an FPGA
one - it's all very slow!  I bet you could use a Picoblazeo to bitbash
it if you put your mind to it though :-)

Cheers,
Martin

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

Article: 118097
Subject: Re: 80000 Bit Shift Register - The Code
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 17 Apr 2007 16:15:47 +0200
Links: << >>  << T >>  << A >>
Eli Hughes wrote:

> always @(posedge Clk)
> begin
> 	MyShift <= MyShift<<1;
> 	MyShift[0] <= SIn;
> 	//This is Needed to make XST happy and not reduce the design to
> 	//a GND net
> 	Out <= MyShift[80000];
> end

I don't know much about Verilog, but if you can use an index into the
MyShift register instead of actually shifting it, maybe your synthesize
program can infer a block ram automaticly.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 118098
Subject: Re: 80000 Bit Shift Register
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 17 Apr 2007 16:17:00 +0200
Links: << >>  << T >>  << A >>
Eli Hughes <emh203@psu.edu> writes:

> I am implementing an 80000 Element Shift register to be used as a
> very long (1Sec) digital delay generator. (Yes, its that big).  It
> is clocked at 80kHz.

At 80kHz you could probably get a 17-bit binary counter running. If
not you can use linear feedback shift register. 

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 118099
Subject: Re: plb_tft_cntlr_ref for an ML405 EDK Project
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Tue, 17 Apr 2007 15:19:12 +0100
Links: << >>  << T >>  << A >>
Hi Peter,

>> The SYS_plbClk port on the TFT reference design needs to be connected to 
>> the same clock as the PLB bus ... The SYS_dcrClk similarly
>> needs to be connected to the clock signal of the DCR bus.
>
> I was wondering whether the non-appearance of these ports in my project 
> was something to with the unexplained nasty error.  Since these have never 
> appeared under ports, I've never connected them up.  This is a naive guess 
> based on the fact that the error occurred whilst doing something to do 
> with clocks.  What do you think?  A red herring?  Is there any way to 
> persuade the "ports" display to show these so that I know they're 
> connected to the correct clock?

The EDK ports view has a "filter" setting which usually hides all the nets 
which have default connections. If the ports are hidden then that probably 
means they've been connected up already. Signals identified as clocks in the 
IP's MPD file are given special treatment, and when they're also identified 
as belonging to a bus interface, the tools should automatically hook them up 
to the appropriate clock source.

The filter settings are accessible via some sort of mouse-click near the top 
of the ports view; can't remember exactly what the button looks like and I 
think it varies from EDK version to EDK version, but it's definitely there.

Cheers,

    -Ben-






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