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 100275

Article: 100275
Subject: Re: done pin didn't go high
From: ghelbig@lycos.com
Date: 5 Apr 2006 23:13:28 -0700
Links: << >>  << T >>  << A >>
If you're sure your programming hardware is OK, then you probably have
a bad bit stream.  The FPGA won't raise done if the stream fails
certain checks.

Are you sure it's formatted correctly for the programming mode?


Article: 100276
Subject: Re: Compressing DVI stream
From: Eric Smith <eric@brouhaha.com>
Date: 05 Apr 2006 23:22:05 -0700
Links: << >>  << T >>  << A >>
ALuPin@web.de wrote:
> I want to know what approach you would recommend to
> compress an incoming DVI data stream (data width 24 bit, pixel clock
> 25-165MHz)
> from 24 bit colour depth to 16 bit colour depth.
>
> Are there algorithms for parallel data processing (24bit/16bit) you
> can recommend ?

To reduce the color depth, you just throw away some of the low order
bits of the color samples.  To get from 24-bit to 15-bit, you throw
away the low order three bits of each sample.  For 16-bit, you can
keep one extra bit of one of the colors; check the interface specs
for 16-bit to see how the bits are allocated.

Article: 100277
Subject: Re: done pin didn't go high
From: Zara <yozara@terra.es>
Date: Thu, 06 Apr 2006 08:35:53 +0200
Links: << >>  << T >>  << A >>
On Wed, 5 Apr 2006 05:25:59 -0700, ahakan <> wrote:

>Thanks for your response, but I am using Parallel Cable IV, so I guess the problem is not due to the parallel cable (I tried the Platform Cable USB as well).


I have the same problem from time to time with PCIV (not tried with
other cables) and XC3S400.

Sometimes it is just a momentary problem, you muts just try again and
it programs OK. Sometimes it is plain stupidity of (I suppose) the
FPGA, switch power off and on again, it usually works.

Best regards,

Zara

Article: 100278
Subject: Re: FSL to VHDL interface
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Thu, 06 Apr 2006 08:48:58 +0200
Links: << >>  << T >>  << A >>
dale.prather@gmail.com wrote:
> John,
> Thank you for your input.  It has helped tremendously.
> 
> Hopefully, just one more question.  When I do this:
> 
>   BUS_INTERFACE SFSL0 = my_fsl_incoming
>   BUS_INTERFACE MFSL0 = my_fsl_outgoing
> 
> I get these two errors, which I think is at the root of the confusion.
> 
> 
> ERROR:MDT - fsl_v20 (my_fsl_incoming) -
>    C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 197 - must
> have
>    atleast 1 master assigned!
> 
> ERROR:MDT - fsl_v20 (my_fsl_outgoing) -
>    C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 210 - must
> have
>    atleast 1 slave assigned!
> 
> For now, to fix it, I've done this:
> 
>  BUS_INTERFACE MFSL0 = my_fsl_incoming
>  BUS_INTERFACE SFSL0 = my_fsl_incoming
>  BUS_INTERFACE SFSL1 = my_fsl_outgoing
>  BUS_INTERFACE MFSL1 = my_fsl_outgoing
> 
> Any comments on the errors or my solution?
> 
> Thanks,
> Dale
> 

Hi,

In your fix you have connect two outgoing FSL ports on MicroBlaze to two 
incoming FSL ports. So this MicroBlaze can send data to itself.
Not sure if this is what you want to do.

Since you want to connect to the outside world of EDK, the tools doesn't 
see a Master-Slave pair in your first attempt. It's the DRC of the tools 
that errors out.

You can't use the BUS_INTERFACE for connect since their is no 
slave/master BUS_INTERFACE for them.
You must connect each signal individual as John proposed in his first reply.

Göran

Article: 100279
Subject: Re: LVDS in Cyclone-II
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 06 Apr 2006 19:06:44 +1200
Links: << >>  << T >>  << A >>
John_H wrote:
> Jim Granville wrote:
> 
>> John_H wrote:
>>
>>> Hello folks,
>>>
>>> I may be starting my first Altera design in a few years but I was 
>>> disappointed to find that the Cyclone-II LVDS drivers aren't true 
>>> differential drives: an external resistor network is needed to 
>>> produce proper LVDS levels like in the "old days."
>>>
>>> Does anyone here have experience with the LVDS drivers?  I imagine 
>>> I'll end up with 0603 resistors rather than a Bourns network, for 
>>> instance.  What have others used?  
>>
>>
>>
>> You could use the quad-smd's = 4 resistors in 1206 or 0805 ?
>>
>> -jg
> 
> 
> I could use "a Bourns network" or the like.  I anticipate using 0603s 
> because they're small, available, routable.  Unless there's experience 
> that says these tiny discretes should, indeed, be a resistor network 
> instead.
> 
> I could use the quad-smd's.  Is there a reason I should?  Shouldn't?
> 
> I'm hoping more for tidbits of experience rather than good ideas.

Mainly it's a packing density issue. IIRC the pitch on the
Quads, matches that of common TQFP packages.
They are also on the right part of the price curve, and
slash the resistor placement bill by 3/4.

-jg



Article: 100280
Subject: Re: Compressing DVI stream
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 6 Apr 2006 00:32:48 -0700
Links: << >>  << T >>  << A >>
Hi,

thank you for your comments.

The system is already working, so hardware should not be changed:

24bit display, 2 DDR Sdram memories @ 133MHz
The 24bit-64bit adaption is no problem at all, adapting 16bit to 64bt
would be even more comfortable.

Andy, concerning the quality of the images through the "compression
process" I can state that the system is used for PC desktop
applications
in most of the cases.

Rgds
Andr=E9


Article: 100281
Subject: Re: Delay value for FDDRCPE in Virtex-II Pro FGPA
From: "Milind" <milindt@gmail.com>
Date: 6 Apr 2006 01:10:18 -0700
Links: << >>  << T >>  << A >>
sorry the delay in timing simulation was due to

default value of ROC_WIDTH

It was like this in the timesim.vhd:
     X_ROC
    generic map (ROC_WIDTH => 100 ns)
    port map (O => GSR);

Actual delay of the element is 4 ns.


Article: 100282
Subject: Inferring SRL in Xilinx FPGA
From: "Rohit Tandon" <rohit2000s@gmail.com>
Date: 6 Apr 2006 02:06:43 -0700
Links: << >>  << T >>  << A >>
I registered a 37-bit signal using an always block in verilog without
reset specification, hoping that a SRL would be inferred if registering
is done without a reset. But ISE still implemented it as a 37-bit
register using flops. Could anyone please let me know if I missed out
something? Any comments/suggestions would be appreciated. Thanks in
advance.


Article: 100283
Subject: Re: Difference in output between testbench and chipscope
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 6 Apr 2006 02:14:16 -0700
Links: << >>  << T >>  << A >>
Hi Subhasri,

are the fifo write data generated internally or
are they external data ?

Rgds
Andr=E9


Article: 100284
Subject: Re: JTAG programing specs for XC18V01 PROM
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Thu, 06 Apr 2006 11:17:45 +0200
Links: << >>  << T >>  << A >>
"David Colson" <dscolson@rcn.com> writes:

> Actually the new ieee1532 bsdl file does describe the programming
> algorithm.

Now I understand why you used the term "decipher". Personally I find
it more straight forward to use SVF.

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: 100285
Subject: Re: Xilinx Schematic Entry
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Thu, 06 Apr 2006 11:01:36 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Wed, 05 Apr 2006 17:47:09 -0700) it happened John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
<a0p832tsdsap1ivpo4ok0fqearc8s6iad1@4ax.com>:

>On 5 Apr 2006 14:00:24 -0700, panteltje@yahoo.com wrote:
>
>>
>>John Larkin schreef:
>>
>>
>>> And if I had the Verilog, the first thing I'd do is grab a piece of
>>> paper and sketch it out to understand what it does.
>>>
>>> Some people think verbally, some visually.
>>>
>>> John
>>OK, so say I wanted a low pass, and wrote:
>>
>>/* 12.5 MHz clock chroma lowpass */
>>`define F0    0
>>`define F1   -2
>>`define F2    2
>>`define F3    8
>>`define F4   -3
>>`define F5  -21
>>`define F6    5
>>`define F7   80
>>`define F8  127
>>`define F9   80
>>`define F10   5
>>`define F11 -21
>>`define F12  -3
>>`define F13   8
>>`define F14   2
>>`define F15  -2
>>`define F16   0
>>
>>
>>module fir( clock, fir_in, fir_out);
>>wire clock;
>>input fir_in;
>>output fir_out;
>>
>>wire [7:0] fir_in;
>>reg [7:0] fir_out;
>>reg [31:0] temp;
>>
>>reg [7:0] sm0;
>>reg [7:0] sm1;
>>reg [7:0] sm2;
>>reg [7:0] sm3;
>>reg [7:0] sm4;
>>reg [7:0] sm5;
>>reg [7:0] sm6;
>>reg [7:0] sm7;
>>reg [7:0] sm8;
>>reg [7:0] sm9;
>>reg [7:0] sm10;
>>reg [7:0] sm11;
>>reg [7:0] sm12;
>>reg [7:0] sm13;
>>reg [7:0] sm14;
>>reg [7:0] sm15;
>>reg [7:0] sm16;
>>
>>
>>always @(posedge clock)
>>begin
>>    sm16 = sm15;
>>    sm15 = sm14;
>>    sm14 = sm13;
>>    sm13 = sm12;
>>    sm12 = sm11;
>>    sm11 = sm10;
>>    sm10 = sm9;
>>    sm9 = sm8;
>>    sm8 = sm7;
>>    sm7 = sm6;
>>    sm6 = sm5;
>>    sm5 = sm4;
>>    sm4 = sm3;
>>    sm3 = sm2;
>>    sm2 = sm1;
>>    sm1 = sm0;
>>    sm0 = fir_in;
>>
>>temp =
>> (`F0 * sm0) + (`F1 * sm1) + (`F2 * sm2) + (`F3 * sm3) +
>> (`F4 * sm4) + (`F5 * sm5) + (`F6 * sm6) +   (`F7 * sm7) +
>> (`F8 * sm8) +  (`F9 * sm9) + (`F10 * sm10) + (`F11 * sm11) +
>> (`F12 * sm12) + (`F13 * sm13) + (`F14 * sm14) + (`F15 * sm15) + (`F16
>>* sm16);
>>
>>fir_out = temp / 512;
>>end
>>
>>----------
>>How would you draw that?
>>
>
>The same way people drew FIR filters before HDLs were invented. It's
>very simple and very intuitive... looks just like an analog
>transversal filter.
>
>John
Sure, possible.
But this IS a lot faster, and more readable in my view.
Actually I tried it that way (you describe), and even to get a 64 order
you will need a BIG piece of paper..... make it 32 wide...
But nobody is stopping you.


Article: 100286
Subject: Re: Inferring SRL in Xilinx FPGA
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Thu, 6 Apr 2006 12:06:41 +0100
Links: << >>  << T >>  << A >>
Hi Rohit,

"Rohit Tandon" <rohit2000s@gmail.com> wrote in message
news:1144314403.793406.220210@e56g2000cwe.googlegroups.com...
> I registered a 37-bit signal using an always block in verilog without
> reset specification, hoping that a SRL would be inferred if registering
> is done without a reset. But ISE still implemented it as a 37-bit
> register using flops. Could anyone please let me know if I missed out
> something? Any comments/suggestions would be appreciated. Thanks in
> advance.

The conditions for SRL16 inference for are:

  (1) No resets (which you've covered);
  (2) Identical clock-enables for all registers, or no clock-enables;
  (3) Output of stage N feeds input of stage N+1 with no intervening logic;
  (4) Output of each stage does not feed any other destination

For example, if you want a parallel-in, serial-out shift register (or
serial-in, parallel-out) then you cannot use SRL16s. Make sure all the
conditions above are met by your circuit.

Also check that SRL16 inference is enabled in your synthesis tool's options
(in your case XST, I guess).

If it still doesn't work, perhaps you could post the code for us to look at?

Cheers,

    -Ben-



Article: 100287
Subject: ddr in virtex2
From: "raphael" <rfonteboa@gmail.com>
Date: 6 Apr 2006 04:17:30 -0700
Links: << >>  << T >>  << A >>
hello folks, i'm working with a avnet board that has a xc2v1500 and
i've been trying to use the ddr memory it has. i can't get it to work,
when i start the placement, edk complains that the placement
constraints, that is the ddr pin assignment, are causing an IOB
conflict. i've tried to use floorplanner to solve the conflicts but it
didn't help. i'll send the error output and if someone knows of
something i can do, or have had the same problem and can help me out i
would be glad.

Phase 12.24
ERROR:Place:17 - The placement constraints of the IOBs
fpga_0_Generic_DDR_DDR_DM_pin<0> and
   fpga_0_Generic_DDR_DDR_DQS_pin<0> makes this design unroutable due
to a physical routing limitation.  This device has
   a shared routing resource connecting the ICLK and OTCLK pins on
pairs of IOBs.  This restriction means that these
   pairs of pins must be driven by the same signal or one of the
signals will be unroutable.  Before continuing please
   remove the placement constraints or move one of these IOBs to a new
location.

ERROR:Place:17 - The placement constraints of the IOBs
fpga_0_Generic_DDR_DDR_CKE_pin and
   fpga_0_Generic_DDR_DDR_DQS_pin<1> makes this design unroutable due
to a physical routing limitation.  This device has
   a shared routing resource connecting the ICLK and OTCLK pins on
pairs of IOBs.  This restriction means that these
   pairs of pins must be driven by the same signal or one of the
signals will be unroutable.  Before continuing please
   remove the placement constraints or move one of these IOBs to a new
location.
Phase 12.24 (Checksum:7270df4) REAL time: 1 mins 9 secs

NOTE: the placement constraints are the ones supplied by the board
manufacturer.

thank's for any help.


Article: 100288
Subject: Re: Inferring SRL in Xilinx FPGA
From: "Marc Randolph" <mrand@my-deja.com>
Date: 6 Apr 2006 04:23:10 -0700
Links: << >>  << T >>  << A >>

Rohit Tandon wrote:
> I registered a 37-bit signal using an always block in verilog without
> reset specification, hoping that a SRL would be inferred if registering
> is done without a reset. But ISE still implemented it as a 37-bit
> register using flops. Could anyone please let me know if I missed out
> something? Any comments/suggestions would be appreciated. Thanks in
> advance.

Howdy Rohit,

SRL inferrance usually works, so to actually be of much help, we need
to know:

1. What synthesis program you're using (XST?  Synplify?)
2. What code you are using for the SRL inferrance (copy and paste a
simplified always block that  you are trying to use)

Good luck,

    Marc


Article: 100289
Subject: Re: LVDS in Cyclone-II
From: "Marc Randolph" <mrand@my-deja.com>
Date: 6 Apr 2006 04:33:31 -0700
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> John_H wrote:
>> > I could use "a Bourns network" or the like.  I anticipate using 0603s
> > because they're small, available, routable.  Unless there's experience
> > that says these tiny discretes should, indeed, be a resistor network
> > instead.
> >
> > I could use the quad-smd's.  Is there a reason I should?  Shouldn't?
> >
> > I'm hoping more for tidbits of experience rather than good ideas.
>
> Mainly it's a packing density issue. IIRC the pitch on the
> Quads, matches that of common TQFP packages.
> They are also on the right part of the price curve, and
> slash the resistor placement bill by 3/4.

When I'm doing a very dense board design, I typically use 0402
resistors because they can be tucked almost anywhere at will.  IE, you
aren't contrained to finding place(s) to set down one or more quad
packs.  Said another way, on average, I think I get better placement on
densely routed boards using single 0402's.  If you lower the density
though, it probably makes sense to go to packs assuming your
manufacturing house can make the boards without solder shorts on the
packs.

Have fun,

    Marc


Article: 100290
Subject: Re: Altera Stratix II GX LVDS max speed
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 6 Apr 2006 05:18:32 -0700
Links: << >>  << T >>  << A >>
Talking with the local apps. eng. it sounds like the speeds may be more
in the 2-300MHz range.  Time to do some reading....


Article: 100291
Subject: Re: USB Interface to Virtex-4
From: "Anonymous" <someone@microsoft.com>
Date: Thu, 06 Apr 2006 12:31:57 GMT
Links: << >>  << T >>  << A >>

"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:1144276764.165125.290340@z34g2000cwc.googlegroups.com...
> Anonymous wrote:
> > Dumb question: Since USB is just a two wire serial interface and all the
USB
> > solutions I've seen are simple, though speedy, microcontrollers why
can't
> > the USB be inside the fpga? Seems like you can instantiate a small micro
> > running at 50 mhz or so with code in a couple block rams to do what the
fx2,
> > for example, does. Apparently, doesn't exist so there must be some
reason?
>
> It's a little more complex than simply two wires between two devices.
>
> USB signalling is half-duplex differential, and high-speed signalling
> is different than full-speed and low-speed.  Also, there are some
> instances where single-ended signalling is used and the driver must be
> capable of doing this and the receiver has to be able to detect these
> states.
>
> -a
>

I agree the software is complicated. (Way too complicated in my opinion.)
But all the solutions out there seem to be built around a little 8-bit
micro. You don't think it's silly to have a 10 million gate FPGA sitting
next to an 8051?

There must be a real reason for it. Maybe I'll try it when I get some time.

-Clark



Article: 100292
Subject: Bizarre behaviour by Quartus?
From: MikeShepherd564@btinternet.com
Date: Thu, 06 Apr 2006 14:22:34 +0100
Links: << >>  << T >>  << A >>
I'm using Verilog with the Altera Cyclone II / Nios II) development
kit.  I'm not yet very experienced with FPGAs.  My present design
creates text to be superimposed on a TV picture or on a raster created
by the FPGA.

At this stage of the design, I read character codes and shapes from
the dev kit flash memory (which was initialised by another
application).  There are no input signals except that I use one of the
dev kit push-buttons to select an NTSC or PAL raster.  That signal is
registered to minimise problems with metastability.

There are two output signals:  composite sync and two-level
(black/white) video, which I combine in a resistor network and feed to
a TV monitor.

In development, I had bizarre behaviour where a minor change to one
part of the design changed the behaviour of completely unconnected
parts.  Simulation did not show these changes.  The result was
corrupted text (incorrect characters selected and/or corrupted
shapes).  Another symptom was that one or more of the dev kit LEDs
would light and in one case the brightness depended on the state of
the push-button.  My design does not drive the LEDs and I have
configured Quartus to set unused pins as "tri-state with weak
pull-up".  (On this development kit, the LEDs are driven by a low
output).

At first, I assumed it must be my fault, but I checked that my design
is fully synchronous.  Quartus reports that it should work up to about
150MHz and I'm using only the on-board 50MHz clock.  The only aspect
of the design unknown to Quartus was the behaviour of the external
flash memory (which I read, but do not write).  But the flash address
is registered to prevent glitches and I don't clock the data until
about twice the access time has elapsed.

The corruption on-screen is quite repeatable.  I ran my fingers along
the pins of the flash device to see if the altered timing made any
change to the display.  It does not.

The results were completely confusing so (since the final design will
not use flash memory) I gave up after a couple of days.  I removed all
my diagnostic signals and the design started to work perfectly !!

I've seen a similar problem today and I now suspect that it is caused
when there are output signals at the top level of the design which are
not assigned to pins.  (This is an easy way to make them appear in the
simulation report).  As I start assigning the diagnostic top-level
signals to unused pins, the problems go away.

Am I missing something here?  Am I making a fundamental mistake or is
there a Quartus option "Connect Unassigned Top-level Signals to Random
Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals
into some Lower-level Module" ?

Mike

Article: 100293
Subject: Re: Inferring SRL in Xilinx FPGA
From: "Rohit Tandon" <rohit2000s@gmail.com>
Date: 6 Apr 2006 06:55:54 -0700
Links: << >>  << T >>  << A >>

Ben Jones wrote:
> Hi Rohit,
>
> "Rohit Tandon" <rohit2000s@gmail.com> wrote in message
> news:1144314403.793406.220210@e56g2000cwe.googlegroups.com...
> > I registered a 37-bit signal using an always block in verilog without
> > reset specification, hoping that a SRL would be inferred if registering
> > is done without a reset. But ISE still implemented it as a 37-bit
> > register using flops. Could anyone please let me know if I missed out
> > something? Any comments/suggestions would be appreciated. Thanks in
> > advance.
>
> The conditions for SRL16 inference for are:
>
>   (1) No resets (which you've covered);
>   (2) Identical clock-enables for all registers, or no clock-enables;
>   (3) Output of stage N feeds input of stage N+1 with no intervening logic;
>   (4) Output of each stage does not feed any other destination
>
> For example, if you want a parallel-in, serial-out shift register (or
> serial-in, parallel-out) then you cannot use SRL16s. Make sure all the
> conditions above are met by your circuit.
>
> Also check that SRL16 inference is enabled in your synthesis tool's options
> (in your case XST, I guess).
>
> If it still doesn't work, perhaps you could post the code for us to look at?
>
> Cheers,
>
>     -Ben-

Thanks to both of you for your quick replies. Actually I was using
output of one stage of the shift register in the logic elsewhere in the
design, when I modified it, XST was infering a SRL (without the need
for XST SRL tool option).

I was wondering if a similar solution can be applied to another problem
where I need to just add some 2-cycles of delay to a 4-bit register.
For instance if I have something like this:

reg [3:0] reg_in ;
reg [3:0] reg_out ;
reg [3:0] reg_r1 ;

always @ (posedge clk)
begin
{reg_out, reg_r1} <= {reg_r1, reg_in} ;
end

Can this logic be modified to make use of SRLs or do I need to
invariably implement it via flops. 

Thanks in advance
-Rohit


Article: 100294
Subject: Re: Bizarre behaviour by Quartus?
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Thu, 06 Apr 2006 06:57:00 -0700
Links: << >>  << T >>  << A >>
MikeShepherd564@btinternet.com wrote:

> Am I missing something here?  Am I making a fundamental mistake or is
> there a Quartus option "Connect Unassigned Top-level Signals to Random
> Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals
> into some Lower-level Module" ?

Quartus does reserve the right to drive "unused"
pins with random internal nodes, which I find
a baffling default.

However I have never seen this happen when
unused pins are assigned to tristate.
I would open case with Altera.

            -- Mike Treseler

Article: 100295
Subject: Re: Bizarre behaviour by Quartus?
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Thu, 6 Apr 2006 16:01:37 +0200
Links: << >>  << T >>  << A >>
Any port in the tio-level-design will become a pin, regardless if it is 
assigned to a location or not. If no location is specified, Quartus will 
choose one for you. I think this behavior cannot be changed (maybe you could 
try "virtual" pins).

Thomas

www.entner-electronics.com

<MikeShepherd564@btinternet.com> schrieb im Newsbeitrag 
news:6o2a32dsbr4vlt9bar7vh7lek3j0v3qfn0@4ax.com...
> I'm using Verilog with the Altera Cyclone II / Nios II) development
> kit.  I'm not yet very experienced with FPGAs.  My present design
> creates text to be superimposed on a TV picture or on a raster created
> by the FPGA.
>
> At this stage of the design, I read character codes and shapes from
> the dev kit flash memory (which was initialised by another
> application).  There are no input signals except that I use one of the
> dev kit push-buttons to select an NTSC or PAL raster.  That signal is
> registered to minimise problems with metastability.
>
> There are two output signals:  composite sync and two-level
> (black/white) video, which I combine in a resistor network and feed to
> a TV monitor.
>
> In development, I had bizarre behaviour where a minor change to one
> part of the design changed the behaviour of completely unconnected
> parts.  Simulation did not show these changes.  The result was
> corrupted text (incorrect characters selected and/or corrupted
> shapes).  Another symptom was that one or more of the dev kit LEDs
> would light and in one case the brightness depended on the state of
> the push-button.  My design does not drive the LEDs and I have
> configured Quartus to set unused pins as "tri-state with weak
> pull-up".  (On this development kit, the LEDs are driven by a low
> output).
>
> At first, I assumed it must be my fault, but I checked that my design
> is fully synchronous.  Quartus reports that it should work up to about
> 150MHz and I'm using only the on-board 50MHz clock.  The only aspect
> of the design unknown to Quartus was the behaviour of the external
> flash memory (which I read, but do not write).  But the flash address
> is registered to prevent glitches and I don't clock the data until
> about twice the access time has elapsed.
>
> The corruption on-screen is quite repeatable.  I ran my fingers along
> the pins of the flash device to see if the altered timing made any
> change to the display.  It does not.
>
> The results were completely confusing so (since the final design will
> not use flash memory) I gave up after a couple of days.  I removed all
> my diagnostic signals and the design started to work perfectly !!
>
> I've seen a similar problem today and I now suspect that it is caused
> when there are output signals at the top level of the design which are
> not assigned to pins.  (This is an easy way to make them appear in the
> simulation report).  As I start assigning the diagnostic top-level
> signals to unused pins, the problems go away.
>
> Am I missing something here?  Am I making a fundamental mistake or is
> there a Quartus option "Connect Unassigned Top-level Signals to Random
> Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals
> into some Lower-level Module" ?
>
> Mike 



Article: 100296
Subject: Re: Difference in output between testbench and chipscope
From: "Subhasri krishnan" <subhasri.krishnan@gmail.com>
Date: 6 Apr 2006 07:01:47 -0700
Links: << >>  << T >>  << A >>
Hi,
The fifo write data is generated internally.

module FifoTest(clk, data_out, d_in);

input clk;
output [7:0] data_out;
output [7:0] d_in;

wire wr_en;
wire rd_en;
wire [7:0] d_in;
wire [7:0] data_out;
reg rd_en_reg;
reg [7:0] data_in_reg;


//Wires tied to values
wire	reset =3D 1'b0;
assign wr_en =3D (reset) ? 1'b0 : 1'b1;
assign rd_en =3D rd_en_reg;

// The following must be inserted into your Verilog file for this
// core to be instantiated. Change the instance name and port
connections
// (in parentheses) to your own signal names.

fifo_8bit_32deep Sync_Fifo (
    .clk(clk),
    .sinit(reset),
    .din(d_in),
    .wr_en(wr_en),
    .rd_en(rd_en),
    .dout(data_out)
	 );

//Generate Data
assign d_in =3D data_in_reg;
always @ (posedge clk)
	if(reset)
		data_in_reg <=3D 0;
	else
		data_in_reg <=3D data_in_reg + 1;

//Read Enable is Delayed Write Enable
reg rd_en_reg_dly1, rd_en_reg_dly2;
always @ (posedge clk)
	if(reset)
		begin
		rd_en_reg_dly1 <=3D 0;
		rd_en_reg_dly2 <=3D 0;
		rd_en_reg		<=3D 0;
		end
	else
		begin
		rd_en_reg_dly1 <=3D wr_en;
		rd_en_reg_dly2 <=3D rd_en_reg_dly1;
		rd_en_reg		<=3D rd_en_reg_dly2;
		end


endmodule

The read enable is a delayed write enable. Please open the link in my
original post to see the testbench waveform and chipscope waveform. I
have highlighted and compared the two outputs. I would like to know why
there is a discrepancy. Thanks for replying.

- Subhasri.K

ALuPin@web.de wrote:
> Hi Subhasri,
>
> are the fifo write data generated internally or
> are they external data ?
>=20
> Rgds
> Andr=E9


Article: 100297
Subject: Xst warning, dangling RAMB16B output
From: "Arlet" <usenet+5@ladybug.xs4all.nl>
Date: 6 Apr 2006 07:09:22 -0700
Links: << >>  << T >>  << A >>
hi,

In my design on a Spartan-3 I use a number of block RAMs. In most of
them, I have a few ports unconnected, but in only one of them I get a
warning:

DesignRules:332 - Blockcheck: Dangling RAMB16B output. Pin DOPB0 of
comp ram is not connected.

The RAM is used across 2 clock domains, and is only read on port A, and
only written on port B. For this reason, inputs on port A are
unconnected, as well as outputs on port B.

here's the instantiation:

RAMB16_S9_S9 ram(
        .WEA(1'b0),
        .ENA(en_a),
        .SSRA(init),
        .CLKA(clock_a),
        .ADDRA(addr_a),
        .DOA(out_a[7:0]),
        .DOPA(out_a[8]),

        .WEB(we_b),
        .ENB(we_b),
        .SSRB(1'b0),
        .CLKB(clock_b),
        .ADDRB(addr_b),
        .DIB(in_b[7:0]),
        .DIPB(in_b[8])
        );

The strange thing is that other block RAMs in the same design, that are
used in similar ways (although not identical), don't elicit any
warnings, even though the same output ports are unconnected.

I'm using XST, ISE Webpack 6.2

Everything works fine, but I'd like to get rid of the warning that's
cluttering up the output.


Article: 100298
Subject: Re: Bizarre behaviour by Quartus?
From: MikeShepherd564@btinternet.com
Date: Thu, 06 Apr 2006 15:38:00 +0100
Links: << >>  << T >>  << A >>
>Quartus does reserve the right to drive "unused"
>pins with random internal nodes, which I find
>a baffling default.
>
>However I have never seen this happen when
>unused pins are assigned to tristate.
>I would open case with Altera.
>
>            -- Mike Treseler

Thanks for that, Mike.  I'll maybe raise it with them when I have more
confidence that I know what I'm doing with Quartus.  For now, at least
I can just make sure not to have unused signals at the top level.

Mike

Article: 100299
Subject: Re: How does the DCM phase shifting circuitry work? Xilinx Spartan3
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 06 Apr 2006 07:57:52 -0700
Links: << >>  << T >>  << A >>
Jim,

I do not think it is any different in this regard, but Steve will 
correct me if I am wrong,

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> 
>> Jim,
>>
>> The tap state machine is always trying to keep one entire period in 
>> one of the delay lines.  This way, the unit is always self 
>> calibrating, it always "knows" how many taps equals one period.
>>
>> So when you ask for 23/256 of a period shift, the arithmetic unit 
>> solves for the closet tap (truncating).
>>
>> To make the silicon take up less space, the delay line itself is 
>> optimized to not change over the PVT (as much as it would otherwise).
>>
>> How this is done is the subject of issued patents, so for those that 
>> are curious, they can look these up.
> 
> 
> Yes, I can follow that for the -3, but Steve was suggesting the 3E was 
> slightly different, so I was wanting to clarify the deails.
> 
> -jg
> 
> 
> 
>>>>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
>>>>
>>>> The Spartan-3E DLL also performs a variable phase
>>>> shift using a delay line.  However, in Spartan-3E, you have raw control
>>>> over the delay.  The shift is always in time, not in some angular unit.
> 
> 



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