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 106275

Article: 106275
Subject: Re: A Newbie question
From: "santanu" <thisissantanu@gmail.com>
Date: 10 Aug 2006 05:49:32 -0700
Links: << >>  << T >>  << A >>

Tommy Thorn wrote:
> Mike Treseler wrote:
> > santanu wrote:
> >
> > > The program compiled fine, and the bitstream was generated
> > > and downloaded successfully. But the problem is now, how
> > > do I see the memory where the result is supposed to be present?
> >
> > Either run a simulation or put a probe
> > on the c_lower pins.
>
> I think he needs more help than that.
>
> Santanu, only a subset of Verilog is synthesizable. Initial contructs
> in particular have no meaning for synthesis and your example is pretty
> nearly a no-op.

First of all, thank you both for replying.

Mike, did you mean a logic analyser probe? If so, we don't have
a logic analyser here as yet. Simulation is not a problem, but
I wanted to see the whether the results were actually stored in the
memory.

Tommy, as you said, if the initial construct is non synthesizable,
then how is a pin set to a default value using verilog? In any case,
isn't the memory location supposed to store the multiplication
result?

In trivial cases, I can see the results by means of turning
the two LEDs on or off, but for a 64 bit multiplied value,
apparently I have no other way to see the result, other than
storing it in memory and reading it in some way, since this
board (the Xilinx Virtex II based Microblaze and Multimedia
Demonstration Board) has no GPIO pins. There are audio,
video, ethernet, rs232 ports, but they require respective
controllers to access them, which I am currently not in a
position to write. I was trying to use the rs232 code from
www.opencores.org, but I could not get it working as yet,
especially since they use a 'wishbone' interface, which I know
nothing about.

Regards,
Santanu


Article: 106276
Subject: Re: EDK peripherals and CoreGen netlists
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Thu, 10 Aug 2006 15:32:27 +0200
Links: << >>  << T >>  << A >>
Guru wrote:
> Hi all,
> 
> I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE
> peripheral project everything is working fine (FIFO netlist is included
> and properly sinthesized and built), but in EDK flow every time i get
> an error during bulid: "unresolved FIFO - missing netlist or pin
> misspeling can cause this..."
> 
> I have of course included in MPD:
> OPTION IMP_NETLIST = TRUE
> OPTION STYLE = MIX
> OPTION RUN_NGCBUILD = TRUE
> 
> and in BDD file:
> Files
> async_fifo.edn
> async_fifo_fifo_generator_v2_3_fifo16_1.edn
> 
> and in PAO FIFO wrapper:
> lib peripheral_v1_00_a async_fifo vhdl
> 
> 
> but the problem persists (and eating my nerves :( ). Files are not
> properly copied (included) to project implementation directory. I
> managed to resolve the problem by manually copying netlists to the imp
> directory, but that is not what I want.
> 
> My methodology obviously doesn't work. Does anyone knows the proper
> procedure to fix this (or is maybe willing to give an example)?
> 
> Cheers,
> 
> Guru
> 

Every time I create a new EDK peripheral which includes cores from 
Coregen it seem to be a struggle to get the ngdbuild tool to find the 
cores. The only think I can think of is that your netlist-catalog is 
either misspelled or that your bbd file has the extension bdd (as you 
have written in your post). If that is not the case you can try to put 
the netlist names on one line as below.

Files
async_fifo.edn, async_fifo_fifo_generator_v2_3_fifo16_1.edn

Regards

-- 
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Article: 106277
Subject: Re: EDK peripherals and CoreGen netlists
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 10 Aug 2006 10:01:14 -0400
Links: << >>  << T >>  << A >>
Many of the Xilinx pcores, e.g. ll_temac use a TCL script to check if a
coregen generated netlist already exists and to generate one it if it
doesn't exist.

/Mikhail



"Guru" <ales.gorkic@email.si> wrote in message
news:1155207923.790368.106990@m73g2000cwd.googlegroups.com...
> Hi all,
>
> I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE
> peripheral project everything is working fine (FIFO netlist is included
> and properly sinthesized and built), but in EDK flow every time i get
> an error during bulid: "unresolved FIFO - missing netlist or pin
> misspeling can cause this..."
>
> I have of course included in MPD:
> OPTION IMP_NETLIST = TRUE
> OPTION STYLE = MIX
> OPTION RUN_NGCBUILD = TRUE
>
> and in BDD file:
> Files
> async_fifo.edn
> async_fifo_fifo_generator_v2_3_fifo16_1.edn
>
> and in PAO FIFO wrapper:
> lib peripheral_v1_00_a async_fifo vhdl
>
>
> but the problem persists (and eating my nerves :( ). Files are not
> properly copied (included) to project implementation directory. I
> managed to resolve the problem by manually copying netlists to the imp
> directory, but that is not what I want.
>
> My methodology obviously doesn't work. Does anyone knows the proper
> procedure to fix this (or is maybe willing to give an example)?
>
> Cheers,
>
> Guru
>



Article: 106278
Subject: Re: Switching two (synchronous) clocks with variable phase difference, without glitching or period loss
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 10 Aug 2006 07:37:55 -0700
Links: << >>  << T >>  << A >>
Peter,
the way you describe your problem, there is (and there can be) no
solution, if you switch asynchronously between two unknown clocks.
You will lose an edge, since you cannot use edges that are very close
to each other.
Assume the two rising edges are 50 ps apart. Are they two edges or one?
How's about 1 ns, etc.?
You must be willing to lose an edge, and the"six easy pices" circuit is
your solution.
Cheers
Peter Alfke, Xilinx
==================
PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
>
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
>
> I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> to be lost. Peter writes "Any clock-switching starts when the
> originally selected clock goes Low, and the Output Clock then stays Low
> until the newly selected clock has first gone Low and then High again."
>
> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.
> 
> Peter.


Article: 106279
Subject: Re: Real-world soft-cpu performance
From: "Antti" <Antti.Lukats@xilant.com>
Date: 10 Aug 2006 08:02:07 -0700
Links: << >>  << T >>  << A >>
Thomas Entner schrieb:

> Hi Antti,
>
> which speed-grades are you talking about? Slowest or fastest?
>
> Thomas
>
Thomas,

the fmax info for each FPGA SoC system should be really checked case by
case,
and 75MHz is generically good choice.
it may be possible to get 100Mhy timing ok in slowest speed and it
maybe that frequencies below 100MHz make problems in highest speed
grade.

so make the system, add the peripheral and run synthesis to see what
goes.

Antti


Article: 106280
Subject: Re: Switching two (synchronous) clocks with variable phase difference,
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 10 Aug 2006 08:07:01 -0700
Links: << >>  << T >>  << A >>
PeterC,

The best I was able to do was to switch using a plain 2:1 multiplexer.

But I followed this with a 'clean up PLL'.  That way, there was no
possibility of ever having a bad clock cycle at the output of the PLL.
If the input to the PLL just goes to a simple XOR phase detector, the
worst that can happen is you build out one clock cycle, either + or -,
over time, sometimes (not always) when you switch.

Since this was used throughout the synchronization and timing systems we
were building, the equipment met Bellcore requirements as a sync source.
 The requirement was that if you had to slip or swallow a clock cycle,
it happened over a long enough period of time that no bit errors were
created in the entire central office, anywhere.

Eventually, if you accumulate an entire frame of 193 bits (old T1 design
made all switch buffers no more than two frames, and many were one
frame) you would drop an entire frame from every line in the central
office (they didn't like that at all).  Since the switch of clocks was
asynchronous, and you could slip or swallow an entire clock period if
the phases were exactly wrong; on average, you did not gain nor lose any
bits in the buffers (all was well).

I do not think there is any way possible to do what you are asking, as
all of my competition did no better, either (and many did worse).

Austin

Aside:  the 193 bit buffer is also related to the total allowed delay
across a switch:  three 125 uS periods (three frames of 193 bits at T1).
 At faster rates, with larger frames, the buffers are obviously allowed
to be larger than 193 bits.

PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
> 
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
> 
> I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> to be lost. Peter writes "Any clock-switching starts when the
> originally selected clock goes Low, and the Output Clock then stays Low
> until the newly selected clock has first gone Low and then High again."
> 
> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.
> 
> Peter.
> 

Article: 106281
Subject: Re: FPGA interface to serial ADC
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 10 Aug 2006 08:55:16 -0700
Links: << >>  << T >>  << A >>

> deriving the SCLK from the LSB of a counter in the FPGA. But this isn't
> working.


Did you succed now with the design?  Did you try the DDR architecture
(assuming full fpga clock speed is needed here ?)


Article: 106282
Subject: Re: Real-world soft-cpu performance
From: google@gornall.net
Date: 10 Aug 2006 09:02:07 -0700
Links: << >>  << T >>  << A >>
Quoth Antti

> The claims for microblaze and ppc fmax have to be read with some
> precaution. In April 2006 Xilinx claimed 200MHz fmax for MicroBlaze 4
> in Virtex-4. Maybe it is possible under some conditions but for me it
> sounds like wishfull thinking. Well I bet MB 5 in Virtex5 in
> "ultracontroller" like setup may run at 200MHz - this is more
> realistic. But some small medium MB.4 system in Virtex-4 does not reach
> 200MHz (at least with current XST synthesis, maybe XST will improve
> timing once again and get better performance). Similarly the 450MHz PPC
> operation defenetly means operation from onchip caches only with no bus
> peripherals at all. So for real applications you better calculate with
> 300MHz cpu clock.

Thanks Antti - good to know :-)

Simon.


Article: 106283
Subject: Re: Switching two (synchronous) clocks with variable phase difference, without glitching or period loss
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 10 Aug 2006 09:17:19 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Peter,
> the way you describe your problem, there is (and there can be) no
> solution, if you switch asynchronously between two unknown clocks.
> You will lose an edge, since you cannot use edges that are very close
> to each other.
> Assume the two rising edges are 50 ps apart. Are they two edges or one?
> How's about 1 ns, etc.?
> You must be willing to lose an edge, and the"six easy pices" circuit is
> your solution.
> Cheers
> Peter Alfke, Xilinx
> ==================
> PeterC wrote:
> > I have two clocks which are relatively synchronous (ie. the frequencies
> > are exactly the same because the originate from the same master clock),
> > but one of the clocks is shifted in phase, and this phase shift is
> > dynamically variable and may be up to one whole period.
> >
> > I need to switch between these two clocks, but without losing rising
> > edges. From my experiments with BUFGMUXs, I appear to be losing a
> > rising edge (post PAR timing simulation).
> >
> > I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> > to be lost. Peter writes "Any clock-switching starts when the
> > originally selected clock goes Low, and the Output Clock then stays Low
> > until the newly selected clock has first gone Low and then High again."
> >
> > I realize that asynchronous clock multiplexing has been covered many
> > times in the group, but I simply can't find a good solution to my
> > specific problem.
> >
> > Peter.

Hi Peter

As much as I dislike disagreeing with the renowned Peter Afke, one can
switch between two asynchronous clocks (in this case as the frequencies
are locked but the phase differs, and can change).

I once designed a hitless switch (in telecom, for DS3) to switch
between two source synchronous bit streams, with a phase asynchronicity
attributable to path delay which was variable, that did not miss a bit
during switching between space diversity receivers (hence hitless :)

That's important in DS3, of course, as missing a bit has a major hit on
framing, so frame relock is then necessary, which was deemed
unacceptable.

It takes a little work but can be done. In that case, I conditioned
both the clocks _and_ the data stream (which could have a significant
bit position offset), which may be overkill here.
Without knowing more about the specifics of PeterC's requirements,
(both for clock rates and phase rate of change apart from overall
structure) it's hard to be specific. I will also mention I used
discrete and analog techniques (ECL for the logic) - this was in the
days before really fast VLSI (or even really fast LSI for that matter,
excepting ECL), but the same techniques could be used simply transposed
completely into the digital domain.

Maybe I'll chew over it over the next couple of days, run up some code
over the weekend and post it (warning : I prefer Verilog ;)

Maybe :)

Cheers

PeteS


Article: 106284
Subject: TIG on Xilinx Asynch FIFO?
From: "Brandon Jasionowski" <killerhertz@gmail.com>
Date: 10 Aug 2006 09:30:19 -0700
Links: << >>  << T >>  << A >>
I am having a hard time getting ISE/XST to ignore clock skew between
two clock domains from an asychronous FIFO generated from CoreGen. Why
is the tool not ignoring this automatically? Here is the error after
Map:

<SNIP>
================================================================================
Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB
HIGH 50%;

 1681 items analyzed, 26 timing errors detected. (26 setup errors, 0
hold errors)
 Minimum period is 3892.500ns.
--------------------------------------------------------------------------------
Slack:                  -1.036ns (requirement - (data path - clock path
skew + uncertainty))
  Source:
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF)
  Destination:
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF)
  Requirement:          0.002ns
  Data Path Delay:      1.038ns (Levels of Logic = 0)
  Clock Path Skew:      0.000ns
  Source Clock:         fx_clk rising at 9607.498ns
  Destination Clock:    CLK_OSC rising at 9607.500ns
  Clock Uncertainty:    0.000ns
  Timing Improvement Wizard
  Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tcko                  0.568
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8
    net (fanout=1)     e  0.100
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp<8>
    Tdick                 0.370
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8
    ----------------------------  ---------------------------
    Total                 1.038ns (0.938ns logic, 0.100ns route)
                                  (90.4% logic, 9.6% route)
</SNIP>

I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns
clock on the read port. I have a TIG setup as follows:

<SNIP>
NET "CLK1_FB" TNM_NET = "CLK1_FB";
TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %;
PIN "U0_DCM.CLK0" TNM = "DCM_CLK0";
PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX";
TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX"  TIG;
#Asynch FIFO clock domains
</SNIP>

CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any
ideas? I'm lost....

Thx,
-Brandon


Article: 106285
Subject: Re: Networking : Multicast Performance
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Thu, 10 Aug 2006 09:46:07 -0700
Links: << >>  << T >>  << A >>
Jeremy Price wrote:
> Hello all,
> 
> I am working with the Xilinx ML403 board and I am trying to find some documentation about the UDP Multicast performance for the board. Does anyone have any pointers?
> 
> Thanks

www.xilinx.com/gsrd has some numbers (basically line rate on 1G) for TCP 
throughput. You could probably extrapolate from that..

/Siva

Article: 106286
Subject: Re: Switching two (synchronous) clocks with variable phase difference, without glitching or period loss
From: "Peter Alfke" <peter@xilinx.com>
Date: 10 Aug 2006 09:50:24 -0700
Links: << >>  << T >>  << A >>
Wow, three Peters in various stages of disagreement...
I suppose it depends on the basic assumptions.
In "6 easy...", I assumed a worst case, where the switching is
asynchronous, and the two clocks have no known phase of frequency
relationship.
In today's posting the two frequencies are identical, but the phase
relationship is unknown. Let's assume the decision to switch is
synchronous with the presently used clock. Then you have to make sure
that the to-be-acquired rising clock edge is at least a clock period
later (otherwise I can get in timing trouble). That assumption
inherently loses one clock transition (except in the extreme case when
both phases are aligned.
If you change the rules, and acept a shorter clock cycle during the
switch-over, things are different, but you now must put a limit on it,
otherwise you get two clock edges that are very close (and how close is
too close ?)
That's why I wrote my skeptical remarks.
Back to the Peters
Peter Alfke.
=====================
PeteS wrote:
> Peter Alfke wrote:
> > Peter,
> > the way you describe your problem, there is (and there can be) no
> > solution, if you switch asynchronously between two unknown clocks.
> > You will lose an edge, since you cannot use edges that are very close
> > to each other.
> > Assume the two rising edges are 50 ps apart. Are they two edges or one?
> > How's about 1 ns, etc.?
> > You must be willing to lose an edge, and the"six easy pices" circuit is
> > your solution.
> > Cheers
> > Peter Alfke, Xilinx
> > ==================
> > PeterC wrote:
> > > I have two clocks which are relatively synchronous (ie. the frequencies
> > > are exactly the same because the originate from the same master clock),
> > > but one of the clocks is shifted in phase, and this phase shift is
> > > dynamically variable and may be up to one whole period.
> > >
> > > I need to switch between these two clocks, but without losing rising
> > > edges. From my experiments with BUFGMUXs, I appear to be losing a
> > > rising edge (post PAR timing simulation).
> > >
> > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> > > to be lost. Peter writes "Any clock-switching starts when the
> > > originally selected clock goes Low, and the Output Clock then stays Low
> > > until the newly selected clock has first gone Low and then High again."
> > >
> > > I realize that asynchronous clock multiplexing has been covered many
> > > times in the group, but I simply can't find a good solution to my
> > > specific problem.
> > >
> > > Peter.
>
> Hi Peter
>
> As much as I dislike disagreeing with the renowned Peter Afke, one can
> switch between two asynchronous clocks (in this case as the frequencies
> are locked but the phase differs, and can change).
>
> I once designed a hitless switch (in telecom, for DS3) to switch
> between two source synchronous bit streams, with a phase asynchronicity
> attributable to path delay which was variable, that did not miss a bit
> during switching between space diversity receivers (hence hitless :)
>
> That's important in DS3, of course, as missing a bit has a major hit on
> framing, so frame relock is then necessary, which was deemed
> unacceptable.
>
> It takes a little work but can be done. In that case, I conditioned
> both the clocks _and_ the data stream (which could have a significant
> bit position offset), which may be overkill here.
> Without knowing more about the specifics of PeterC's requirements,
> (both for clock rates and phase rate of change apart from overall
> structure) it's hard to be specific. I will also mention I used
> discrete and analog techniques (ECL for the logic) - this was in the
> days before really fast VLSI (or even really fast LSI for that matter,
> excepting ECL), but the same techniques could be used simply transposed
> completely into the digital domain.
>
> Maybe I'll chew over it over the next couple of days, run up some code
> over the weekend and post it (warning : I prefer Verilog ;)
> 
> Maybe :)
> 
> Cheers
> 
> PeteS


Article: 106287
Subject: synthesis intelligence of quartus regarding range of values
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 10 Aug 2006 09:54:53 -0700
Links: << >>  << T >>  << A >>
I got a "circuit", which is doing integer division with large values. I
instantiated a MEGAWIZ-devider with currently 48bits / 16 Bits, which
ist fed with some more bits (done be shifting) in order to obtain a
result with a higher accuracy than 1 in one step without proceeding the
remainder.

E.g. I am shifting with 10 Bits and fill the rest with zero:
input <= "0000" & Value (33 downto 0) & "0000000000"

I recognize, that Quartus is obviously capable of synthesizing away to
signals / paths in the devider which are not needed.

Now, what is about the range of values ? In my design, the A / B have a
certain relationship, so that the result can never exceed 18 bits,
whereby the vector of the result (devider out) has of course 48 bits.

Is it of an advantage if the range of values is restricted?

Currently I am cutting away the first bits, which will always be zero.
s there anything more, I can do, to keep the design small ?


Article: 106288
Subject: Altera SOPC ModelSim question
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 10 Aug 2006 19:12:36 +0200
Links: << >>  << T >>  << A >>
I'm trying to construct a SOPC component of JOP [1].
As it did not work in the FPGA on the first try
(of course) I would like to simulate it with ModelSim
(Altera version).

However, when I start ModelSim from Quartus I get following
error:

# ** Error: (vcom-11) Could not find C:\altera\Modeltech_ae\win32aloem/../altera/vhdl/altera.altera_europa_support_lib.
# ** Error: D:/usr/cpu/jop/quartus/tmp/jop_system.vhd(24): (vcom-1195) Cannot find expanded name:
'altera.altera_europa_support_lib'.
# ** Error: D:/usr/cpu/jop/quartus/tmp/jop_system.vhd(24): Unknown record element "altera_europa_support_lib".


I found the VHDL file in the Quartus directory. Do I need to
compile it (once ?) with ModelSim, or is there a PATH issue?

Versions: Quartus 6.0sp1, ModelSim ALTERA 6.1d

Thanks,
Martin


[1] http://www.jopdesign.com/ 



Article: 106289
Subject: Re: MIG 1.6 DDR2 testing problems (FIFO16 related?)
From: Joseph Samson <user@example.net>
Date: Thu, 10 Aug 2006 17:16:45 GMT
Links: << >>  << T >>  << A >>
heinerlitz@gmx.de wrote:
> HI,
> 
> I am sorry I am running Mig 1.5 was a typo.
> 
> Right now iam encountering two problems:
> 
> If i post a sequence of reads to the read fifo, the first one always
> fails than I have several succesful reads. I posted 256 writes and
> sucessive reads and they were all succesfull besides the first one.
> Strangely inl in a really long succesive write then read out sequence
> (1k read ops) the first 100 are not succesfull and then I get 256
> succesful read outs and the again errors for the remaining ones. Often
> the read out values are almost correct like only some 2-3 bits
> different..

When the first or last element of a burst is missing, it could be a sign 
that the pipelining is off somewhere.  For example, you expect data to 
arrive after 4 clocks, but it comes after 3 clocks and so you miss the 
first one. Often this is paired with an unexpected data value at the 
end. At least this is a repeatable problem. Sounds like another job for 
ChipScope.

> 
> 
>>If these values never change, then you don't have the same problem that
>>I did.
> 
> But then again I hardcoded the observed (static) values and NOTHING
> worked anymore. Idont know if I can trust chipscope.

Whenever I find (rarely) ChipScope giving me impossible answers, I 
invariably discover that either I'm not looking where I thought I was or 
that my circuit doesn't work the was that I assumed it would.

> 
> How did you decide to hardcode the values? Are the rising and falling
> clk_count connected in some way like if one is reg3 teh other one is
> also reg3?
I hard coded the values because I notcied that they weren't always the 
same after calibration. As you stated before, this doesn't seem to be a 
problem that you have.


---
Joe Samson
Pixel Velocity

Article: 106290
Subject: Re: xst synthesis with attributes failure
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 10 Aug 2006 17:30:10 GMT
Links: << >>  << T >>  << A >>
Hi Evan, thanks for your response.

The code was originally written for the Leonardo synthesiser, and at the 
time the synthesis attribute needed to be given as a string, but the 
simulation generic was a ulogic_vector. (We wrote our own simulation models 
for the primitives to support ulogic).
Most of the INITs are static "2345" etc so to avoid possible errors between 
synthesis and simulation the 'init trick works quite well.

until XST that is ....

in this case RAM16X1D is a xilinx primitive, so I would have to put the 
"1234" in the generic as well I guess.

a_core : if true generate
>attribute INIT of ramd : label is "1234";
>begin
>  ramd : RAM16X1D
>    generic map (
>      INIT => str2suv(ramd'INIT)  <<<< here is the problem

For XST I think (I will test this) the generic on it's own will give the 
correct synthesis result, but then I can't run it through Leonardo again.
Cheers,
Mike. 



Article: 106291
Subject: Re: Unpicking Logical Synthesis
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 10 Aug 2006 17:32:20 GMT
Links: << >>  << T >>  << A >>
>
> I thought the ngc2edif tool might come into it somewhere, but how
> exactly do I end up with a VHDL file?
>
> Cheers,
>
> Robin
Mentor tools such as Leonardo or Precision can take an EDIF and produce a 
VHDL file - it's not terribly readable, but you can simulate it.
I am sure the other vendors can do the same trick.
/Mike 



Article: 106292
Subject: Re: ISE software bug???
From: "Jozsef" <bit_vector@tvn.hu>
Date: 10 Aug 2006 11:10:41 -0700
Links: << >>  << T >>  << A >>
So, the secret seems to be solved. The problem is based on serial slave
configuration routines. Via JTAG, the FPGA runs correctly, but same
configuration stream on serial slave cannot. And I read many
documentation PDFs, PPTs, HTML sites for the sollution. Now, I got a
little success, now I'm passed the problem to microcontroller
programmer group.
 About the problem: only one CCLK clock period sended to fpga after
DONE pin rising to high, other documents tells this clock period must
be three cycles after DONE rising high (XAPP098): one to IOs activate,
one to GSR release and the last cycle to begin user operation.

now I'm waiting for the programmers group response with a correct
firmware of MCU.

Thank you for the powerfull help!

Best regards
Jozsef

Marc Randolph wrote:
> Aurelian Lazarut wrote:
> > I would check (at least) two things,
> > 1. If the board finishes the configuration process gracefully, I mean
> > DONE goes high, start-up clock need to be matched with your config type
> > (jtagclk or cclk or userclk) mode pins are set correctly.
>
> But beware of  in slave select-map mode, when DONE really means "not
> quite done yet" or "you're almost done".  By default, CCLK has to be
> strobed several more times after DONE goes high.
> 
> Have fun,
> 
>    Marc


Article: 106293
Subject: Re: xst synthesis with attributes failure
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 10 Aug 2006 18:42:25 GMT
Links: << >>  << T >>  << A >>
found one solution, adding -- pragmas to stop XST seeing the problem :)

attribute INIT  of mux4_lut1 : label is "00CA";
begin

  mux4_lut1:  LUT4
    --pragma translate_off
    generic map (
      lut => str2suv(mux4_lut1'INIT)
      )
    --pragma translate_on
    port map (
        I0 => DIN0(i), 



Article: 106294
Subject: Anyone really using Virtex-5 FPGAs yet?
From: "pomerado@hotmail.com" <pomerado@hotmail.com>
Date: 10 Aug 2006 11:49:34 -0700
Links: << >>  << T >>  << A >>
Which parts?

How long was delivery?

What is the cost?

What development/OEM boards are available?


Article: 106295
Subject: Re: Who is your favourite FPGA guru?
From: "Marlboro" <ccon67@netscape.net>
Date: 10 Aug 2006 12:20:53 -0700
Links: << >>  << T >>  << A >>

burn.sir@gmail.com wrote:
> Gurus just talk ...
> 
No, they jump around


Article: 106296
Subject: Re: EDK peripherals and CoreGen netlists
From: "Guru" <ales.gorkic@email.si>
Date: 10 Aug 2006 12:26:55 -0700
Links: << >>  << T >>  << A >>
Yes, Mikhail I know that. In fact I sucesfully implemented tcl script
to generate fifo on the fly. But to properly create argument file
(.arg) file for the purpose is a real "black magic" without a user
manual (if it only exsisted). Right now I am on that mission to crate
an arg file for fifo with asymetric ports. It is much easier to create
a netlist and include it in /netlist directory.

Damn Xilinx, how can they make life miserable.

Cheers,

Guru

MM wrote:
> Many of the Xilinx pcores, e.g. ll_temac use a TCL script to check if a
> coregen generated netlist already exists and to generate one it if it
> doesn't exist.
>
> /Mikhail
>
>
>
> "Guru" <ales.gorkic@email.si> wrote in message
> news:1155207923.790368.106990@m73g2000cwd.googlegroups.com...
> > Hi all,
> >
> > I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE
> > peripheral project everything is working fine (FIFO netlist is included
> > and properly sinthesized and built), but in EDK flow every time i get
> > an error during bulid: "unresolved FIFO - missing netlist or pin
> > misspeling can cause this..."
> >
> > I have of course included in MPD:
> > OPTION IMP_NETLIST = TRUE
> > OPTION STYLE = MIX
> > OPTION RUN_NGCBUILD = TRUE
> >
> > and in BDD file:
> > Files
> > async_fifo.edn
> > async_fifo_fifo_generator_v2_3_fifo16_1.edn
> >
> > and in PAO FIFO wrapper:
> > lib peripheral_v1_00_a async_fifo vhdl
> >
> >
> > but the problem persists (and eating my nerves :( ). Files are not
> > properly copied (included) to project implementation directory. I
> > managed to resolve the problem by manually copying netlists to the imp
> > directory, but that is not what I want.
> >
> > My methodology obviously doesn't work. Does anyone knows the proper
> > procedure to fix this (or is maybe willing to give an example)?
> >
> > Cheers,
> >
> > Guru
> >


Article: 106297
Subject: Re: A Newbie question
From: "Brian McFarland" <brian.mcf1985@gmail.com>
Date: 10 Aug 2006 13:03:04 -0700
Links: << >>  << T >>  << A >>
> Tommy, as you said, if the initial construct is non synthesizable,
> then how is a pin set to a default value using verilog? In any case,
> isn't the memory location supposed to store the multiplication
> result?
>
> Regards,
> Santanu

Some devices allow you to assign default/startup values to registers.
It can be done for Altera parts through assignment editor.  A common
alternative (and i think generally accepted as better) approach is to
have a reset signal, which triggers an "always" block.  i.e.

module somemodule(... rst, ..., outA ...)
  ...
  output [31:0] outA;
  reg [31:0]  out_regA;
  ...
always @(posedge rst) begin
  out_regA <= 32'h00000000;
end
...
...
end module


Article: 106298
Subject: Re: Altera SOPC ModelSim question
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 10 Aug 2006 13:47:11 -0700
Links: << >>  << T >>  << A >>


> I found the VHDL file in the Quartus directory. Do I need to
> compile it (once ?) with ModelSim, or is there a PATH issue?

Compile it.

KJ


Article: 106299
Subject: Re: Simple code to check out Spartan3 starter kit?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 10 Aug 2006 21:57:03 GMT
Links: << >>  << T >>  << A >>
In article <FsvCg.13358$rd1.2604@trnddc01>, Nevo <nevo_n@hotmail.com> wrote:
>Just plug it into the wall.  The PROM comes preloaded with demo code that 
>makes the blinkylights and countynumbers.  (At least, the one I got last 
>week does...)
>

True, but what I was looking for was a VHDL example for displaying things 
on the various blinylights, etc.  Someone else linked to some code at 
Xilinx that apparently does those things.

Phil



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