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 144275

Article: 144275
Subject: FPGA + ASIC: generate signals and readout
From: Konx <cescozep@gmail.com>
Date: Tue, 24 Nov 2009 02:05:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi.

I have the following situation, it is a bit complicated to explain but
I hope I can make myself clear.

- I have a board (called S1) with an FPGA on it, and other stuff
(microcontroller, many connectors, memory, etc...). The only thing I
think it is useful to know for you, is that I have access to the FPGA
via USB cable.
- In another board (called S2) I have an ASIC chip to test.

At the present time, I'm able to load a simple bitstream (generated
using Xilinx ISE environment) on the FPGA. I can load this bitstream
because someone wrote a simple driver to control the FPGA, so I can
just start the program, press a "browse" button to select the
bitstream and press the "upload" button to load the bitstream.

In the next days, I have to write a simple Verilog code to provide
signals to the FPGA (like token, trigger, etc...not important).

Given these signals, the chip has to perform some operation, and it
gives me an output. The output is a serial data of 48 bit.

Here start the problems:

- I have to store the data somewhere in the FPGA, so I was thinking
that I could create some RAM (using the Core Generator for example)
and then store the data inside these kind of register.
- Then, I have to read out the FPGA. To do this, I have a C++ header
file with some functions in it, that I can use to read out the data.

Questions:
- do you think that the RAM solutions is ok? are there any better ways
to store the data?
- is there another way to read out the chip? I mean, suppose I don't
have the C++ functions, is it still possible to read the data arriving
at a certain pin of the FPGA? I think it should be possible, but at
the moment I have no idea how to do this. Moreover, I need to store
these data in a file...I guess this should be possible too.

I know that the problem is quite general but if you could give me some
guidelines I would really appreciate it, so at least I know what I
have to search for.

Thank you for any help

Francesco.

Article: 144276
Subject: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Claytong_nz <clayton@isnotcrazy.com>
Date: Tue, 24 Nov 2009 03:16:23 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I'm hoping someone can help me!
I'm part of a group doing an amateur radio satellite project
(KiwiSAT). We have a bug in some logic in the above Quicklogic device.
Due to ITAR the guys that initially developed this logic cannot help
with the bug fix or programming a device. We don't have access to the
tools (Quickworks I think) or the programmer. Can anyone outside the
US help us with the SW tools and the use of a programmer for this (now
obsolete) device!
We may have found a supply of the part, but if anyone can help here
also it would be great!

Regards
Clayton

Article: 144277
Subject: Re: NIOS and ftoa()
From: Michael S <already5chosen@yahoo.com>
Date: Tue, 24 Nov 2009 03:16:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 18, 7:19 pm, "John Speth" <johnsp...@yahoo.com> wrote:
> Hi folks-
>
> I'm in the beginning stages of crafting a high-speed measurement device
> which needs to output a floating point value in ASCII string form that
> represents the measurement at a rate of 10 kHz.  I'm using an Altera FPGA
> that runs Nios2.  Convenient standard library functions like sprintf() or
> ftoa() running as code will be too time-consuming to meet my high throughput
> requirements.  What I need is an ultrafast float to ASCII conversion
> function that can run in code *or* a strategy for implementing a conversion
> function in HDL.  Altera has a nice tool called C to HDL compiler which I'm
> looking at now.
>
> It seems to me that a fast float to ASCII conversion function would be a
> common function of many embedded systems.  Rather than me reinventing the
> wheel, can anyone point me to a resource (example on the web or a product
> for sale) that I can use to achieve my goal?
>
> Thanks, John Speth.

It seems your task not just doesn't require floating-point to ASCII
conversion, it needs no floating point at all. I'd go as far as to say
that even if there was fast floating point hardware I'd still prefer
to not use it for that type of task.
Use fix point!
Suppose, you have 14-bit ADC with 3V unipolar scale and you want to
present the result in mV with three digits after decimal point. All
you need to do is something like:

const int ADC_CODE_TO_uV_NUM = int(3E6);
const int ADC_CODE_TO_uV_DEN = 1<<14;
unsigned result_uV = (unsigned)(((long long)result_code *
ADC_CODE_TO_uV_NUM*2 + ADC_CODE_TO_uV_DEN)/(ADC_CODE_TO_uV_DEN*2));
char result_uV_str[32];
int len1 = siprintf(result_uV_str, "%04u", result_uV);
char result_mV_str[32];
memcpy(result_mV_str, result_uV_str, len1 - 3);
result_mV_str[len1 - 3] = '.';
memcpy(&result_mV_str[len1 - 3 + 1], &result_uV_str[len1 - 3],  3);
result_mV_str[len1 + 1] = 0;

Article: 144278
Subject: Deskew Reginal clock input
From: bonnerfme <xiaoling.li@fme.fujitsu.com>
Date: Tue, 24 Nov 2009 05:07:29 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi there,

I have a question regarding clock deskewing. My design has a sub
module that gets its clock signal from a regional clock pin, however,
the clock skew is too large and causing timing violations.

I read about something on DCM and thought about using it to deskew
this regional clock, but it seems to me that DCM can only be used in
conjunction with global clock lines. The board layout is fixed, which
means no way I can use a global clock line for this signal, have to
live with it.

Has anybody experience with regional clock deskewing?

Thanks a lot!

Article: 144279
Subject: Re: Microblaze interconnection
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Tue, 24 Nov 2009 13:21:54 +0000
Links: << >>  << T >>  << A >>
Alexey <trenkoff@gmail.com> writes:

> Hello,
>
> I need to connect two Microblaze processors,  each on a seperate
> Spartan 3e chip, but on the same board. Can this be done through FSL?
> Would it require two seperate projects in the XPS? Is there an example
> or tutorial on this subject?

To add to Austin's suggestions, a simple UART link would be very easy if
the bandwidths are low. Two pins (crossed over :) and simple software.

However you do it, you would need two projects in XPS, unless there is
enough commonality in the peripherals and pinouts that you could make
one bitstream do the whole job for both FPGAs.

I doubt you'll find much in the way of examples - multiprocessor
systems with microblazes in separate chips are a bit thin on the ground!

Cheers,
Martin

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

Article: 144280
Subject: Re: Deskew Reginal clock input
From: Gabor <gabor@alacron.com>
Date: Tue, 24 Nov 2009 05:49:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 24, 8:07=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote:
> Hi there,
>
> I have a question regarding clock deskewing. My design has a sub
> module that gets its clock signal from a regional clock pin, however,
> the clock skew is too large and causing timing violations.
>
> I read about something on DCM and thought about using it to deskew
> this regional clock, but it seems to me that DCM can only be used in
> conjunction with global clock lines. The board layout is fixed, which
> means no way I can use a global clock line for this signal, have to
> live with it.
>
> Has anybody experience with regional clock deskewing?
>
> Thanks a lot!

Are you sure you mean deskew?  That is a routing issue.  I don't
see how a DCM would help unless you're talking about the skew
between the regional clock and some other clock.

Confused,
Gabor

Article: 144281
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 24 Nov 2009 15:15:41 +0100
Links: << >>  << T >>  << A >>
On Tue, 24 Nov 2009 03:16:23 -0800 (PST), Claytong_nz wrote:

>I'm part of a group doing an amateur radio satellite project
>(KiwiSAT). We have a bug in some logic in the above Quicklogic device.
>Due to ITAR the guys that initially developed this logic cannot help
>with the bug fix or programming a device. We don't have access to the
>tools (Quickworks I think) or the programmer. Can anyone outside the
>US help us with the SW tools and the use of a programmer for this (now
>obsolete) device!
>We may have found a supply of the part, but if anyone can help here
>also it would be great!

I have a programmer I could lend/sell, and a few 12x16 84-pin parts 
(no 68-pin or 8x12 AFAIK, but you could easily make up an adapter).

I may also be able to dredge up an archived copy of the tools,
but they ran under Win3.1 so you may need a museum-piece PC
to use them.

And of course there's the small difficulty of 12,000 miles
between you and me :-)

It might be better for you to get some small modern CPLD
and emulate, rather than replace, the old QL8x12.  They were
cute little parts but there's not much logic in 'em (only
96 FFs and associated AND/MUX logic, right?) so even a 
modest CPLD should do the job.  And you may still be able
to find CPLDs with 5V I/O, which is likely to be your most
troublesome stumbling block.
-- 
Jonathan Bromley

Article: 144282
Subject: Re: Deskew Reginal clock input
From: austin <austin@xilinx.com>
Date: Tue, 24 Nov 2009 07:39:48 -0800 (PST)
Links: << >>  << T >>  << A >>
a,

The DCM has a fixed phase shift feature, so you can "move" the clock
outputs, anywhere you want, from 0 to 360 degrees, with 1/256
resolution.

Austin

Article: 144283
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: austin <austin@xilinx.com>
Date: Tue, 24 Nov 2009 07:47:47 -0800 (PST)
Links: << >>  << T >>  << A >>
Jonathon,

CPLDs will fry themselves in space (latchup and die).

This is well known in the aerospace community:  do not put a CPLD in
space!

de AB6VU
(Austin)

Article: 144284
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 24 Nov 2009 17:56:09 +0100
Links: << >>  << T >>  << A >>
On Tue, 24 Nov 2009 07:47:47 -0800 (PST), austin <austin@xilinx.com>
wrote:

>Jonathon,
>
>CPLDs will fry themselves in space (latchup and die).
>
>This is well known in the aerospace community:  do not put a CPLD in
>space!

OK, didn't realize he was planning to fly the thing :-)
-- 
Jonathan

Article: 144285
Subject: Re: Deskew Reginal clock input
From: bonnerfme <xiaoling.li@fme.fujitsu.com>
Date: Tue, 24 Nov 2009 09:31:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 24, 2:49=A0pm, Gabor <ga...@alacron.com> wrote:
> On Nov 24, 8:07=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote:
>
> > Hi there,
>
> > I have a question regarding clock deskewing. My design has a sub
> > module that gets its clock signal from a regional clock pin, however,
> > the clock skew is too large and causing timing violations.
>
> > I read about something on DCM and thought about using it to deskew
> > this regional clock, but it seems to me that DCM can only be used in
> > conjunction with global clock lines. The board layout is fixed, which
> > means no way I can use a global clock line for this signal, have to
> > live with it.
>
> > Has anybody experience with regional clock deskewing?
>
> > Thanks a lot!
>
> Are you sure you mean deskew? =A0That is a routing issue. =A0I don't
> see how a DCM would help unless you're talking about the skew
> between the regional clock and some other clock.
>
> Confused,
> Gabor

Hi Gabor, you're right, this is a routing issue.I meant the skew just
on this regional clock, not the skew between it and some other clock.
Maybe DCM is not the right thing to go for, I'm no sure, please advise
what is the correct thing I should look into.

BR

Article: 144286
Subject: Re: Deskew Reginal clock input
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 24 Nov 2009 10:04:01 -0800
Links: << >>  << T >>  << A >>
bonnerfme wrote:

> My design has a sub
> module that gets its clock signal from a regional clock pin, however,
> the clock skew is too large and causing timing violations.

You could make a synchronous divide by n +- cal ppm
using a phase accumulator. A host computer
could do the time error to delta cal calculation
if the integrated time error can be measured.

         -- Mike Treseler

Article: 144287
Subject: Re: Deskew Reginal clock input
From: "Steve Ravet" <steve.ravet@arm.com>
Date: Tue, 24 Nov 2009 15:30:32 -0600
Links: << >>  << T >>  << A >>
input violations, output violations, or flop/flop violations?

Is your clock being routed using logic routing resources or a dedicated 
clock resource?  Your clock needs to go on a global clock line if it isn't 
there already.  It's hard to meet timing with clocks on logic routing, maybe 
with some careful hand placement you could do it.

--steve

"bonnerfme" <xiaoling.li@fme.fujitsu.com> wrote in message 
news:3a29c0c0-14cf-4289-92ee-aaf972ef2af7@t18g2000vbj.googlegroups.com...
: Hi there,
:
: I have a question regarding clock deskewing. My design has a sub
: module that gets its clock signal from a regional clock pin, however,
: the clock skew is too large and causing timing violations.
:
: I read about something on DCM and thought about using it to deskew
: this regional clock, but it seems to me that DCM can only be used in
: conjunction with global clock lines. The board layout is fixed, which
: means no way I can use a global clock line for this signal, have to
: live with it.
:
: Has anybody experience with regional clock deskewing?
:
: Thanks a lot! 



Article: 144288
Subject: Re: Deskew Reginal clock input
From: Gabor <gabor@alacron.com>
Date: Tue, 24 Nov 2009 13:31:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 24, 12:31=A0pm, bonnerfme <xiaoling...@fme.fujitsu.com> wrote:
> On Nov 24, 2:49=A0pm, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Nov 24, 8:07=A0am, bonnerfme <xiaoling...@fme.fujitsu.com> wrote:
>
> > > Hi there,
>
> > > I have a question regarding clock deskewing. My design has a sub
> > > module that gets its clock signal from a regional clock pin, however,
> > > the clock skew is too large and causing timing violations.
>
> > > I read about something on DCM and thought about using it to deskew
> > > this regional clock, but it seems to me that DCM can only be used in
> > > conjunction with global clock lines. The board layout is fixed, which
> > > means no way I can use a global clock line for this signal, have to
> > > live with it.
>
> > > Has anybody experience with regional clock deskewing?
>
> > > Thanks a lot!
>
> > Are you sure you mean deskew? =A0That is a routing issue. =A0I don't
> > see how a DCM would help unless you're talking about the skew
> > between the regional clock and some other clock.
>
> > Confused,
> > Gabor
>
> Hi Gabor, you're right, this is a routing issue.I meant the skew just
> on this regional clock, not the skew between it and some other clock.
> Maybe DCM is not the right thing to go for, I'm no sure, please advise
> what is the correct thing I should look into.
>
> BR

What kind of device are you using?  Is this "Regional clock"
driven by a dedicated clock buffer like a BUFR in the Virtex 5?
Or do you mean you're using non-global routing resources for
the clock?

Article: 144289
Subject: Re: Initializing color bars on CH7301
From: Arnim <clv.5.minral@spamgourmet.com>
Date: Tue, 24 Nov 2009 23:04:08 +0100
Links: << >>  << T >>  << A >>

>> The CH7301 required exact waveforms on the H, V & DE pins (I chose VGA
>> mode 0, 640x480), otherwise the display wouldn't sync. I went for
>> "sample 2x", i.e. XCLK and XCLK* toggle with 25 MHz, phase shifted by
>> 180 deg. Guess proper XCLK/XCLK* clocking is essential to sample H, V
>> and DE.
> 
> Does "VGA mode 0" refer to the IDF bits? Also, did you just choose 25MHz
> randomly because it was less than 36MHz as Table 2: DVI Outputs in the
> CH7301 datasheet says?

With mode 0 I was referring to the standard VGA mode 640x480 @ 60 Hz.
That's not related to any CH7301 settings, though

The 25 MHz is the pixel clock for this mode (25.175 MHz to be precise).
Also see http://tinyvga.com/vga-timing/640x480@60Hz

In general, my strategy to get a color bar test pattern was to operate
the CH7301 as if it was used to output image data: Configure and drive
the chip as in the final application, just without video data applied.
I guess the chip won't "do anything for you" except sketching colorful
bars. You need to provide framing, sync timing etc. yourself.

>> I2C commands were applied according to AN-41, "Figure 4: Single Step
>> Writes". I.e. n times the sequence, SPC @ ~195 kHz:
> 
> Was 195Khz a random choice of speed as well?

Yes, a frequency within the respective CH7301 spec (it's 25 MHz / 128).

> Did you have to write custom VHDL to do the timings for the V and H pins?

Yes, a set of counters to generate H & V sync signals plus DE. The
CH7301 embeds the horizontal and vertical sync information in the DVI
stream under control of DE. I assume that the color pattern test mode
simply fills in the display information but requires framing from external.

BTW after some experimenting I went for the ODDR2 double data rate
output registers for XCLK/XCLK* and video data and used the
clock-vs-data phase shift feature for the CH7301. Alternatively, one
could trim the video data outputs vs XCLK with DLL resources on the FPGA.

> Did you use the 25MHz clock you chose above and the chosen resolution of
> 640x480 to determine the H and V input lines?

Again, yes. 25 MHz is the pixel clock frequency and it's used to
generate the sync waveforms on H, V & DE. The same way as for VGA
monitors/displays: H sync, V sync - DE is esentially the blanking signal
covering also the front and back porches around active sync.

> Does having the H and V
> active low mean that the "active time" for outputting RGB values is when
> you drop these signal lines?

The VGA mode requires negative polarity on these lines, therefore I set
this configuration and generated active low waveforms on the pins
accordingly.
Video data is accepted by the CH7301 when DE is 1. DE needs to be 0 to
mux the H and V waveforms into the DVI stream.

> I know there are lots of questions here and thanks for your help so far, I
> don't know why there isn't better documentation for implementing this
> chip... 	   

You're welcome :-) I had quite some headaches as well when struggling
with this chip (and the docs). Once it's set up, fine. But until then
the docs don't give you much clue how to start with it.

The DVI spec http://www.ddwg.org/lib/dvi_10.pdf (especially chapter 3)
was helpful. It clarified some of background topics like the meaning of
DE.

Arnim

Article: 144290
Subject: Going mad trying to solve PLL setup/hold timing violation issues in
From: Philip Pemberton <usenet09@philpem.me.uk>
Date: 25 Nov 2009 00:45:49 GMT
Links: << >>  << T >>  << A >>
Hi guys,
  I'm trying to generate a clock signal that can be switched between 
16MHz, 8MHz and 4MHz, and have a 50% duty cycle (for a data separator/
slicer). Just to make this difficult, I only have a 40MHz master clock to 
work from... which only has an even integer factor for 4MHz (divide-by-
ten). Divide-by-five gets 8MHz, but doesn't give a 50:50 ratio. 16MHz 
isn't even possible (nearest I can get is 20MHz with a divide-by-two).

  This is on an Altera Cyclone II 2C20, FBGA484 package, on a Terasic DE1 
(actually Altera Cyclone II Starter Board, but the Terasic board is 
essentially identical) development board. Software is Quartus 9.0.

  Originally, this seemed like a simple problem to solve -- create a PLL 
to generate a new set of clocks that were phase-locked to the original 
40MHz master clock. Problem is, while I can get the PLL to generate a 
16MHz clock, it won't go any lower -- 8MHz and 4MHz produce an alert to 
the effect of "division ratio not possible."

  So I figured I'd go about this a different way -- generate a 16MHz 
clock with the PLL, then divide it down to 8MHz and 4MHz with a pair of 
DQ flip-flops wired to toggle (or a binary counter, whatever worked). 
This worked fine when I tied the outputs of the clock divider straight to 
the clock input on the data separator.

  This is what I have now:

	// Instantiate a PLL to convert from 40MHz to 32MHz
	wire CLK_PLL16MHZ;
	DatasepClockGen dscg(CLK40MHZ, CLK_PLL16MHZ);

	// Divide down the 16MHz reference to get 8MHz and 4MHz
	reg CLK_PLL8MHZ;
	always @(posedge CLK_PLL16MHZ) CLK_PLL8MHZ = ~CLK_PLL8MHZ;
	reg CLK_PLL4MHZ;
	always @(posedge CLK_PLL8MHZ) CLK_PLL4MHZ = ~CLK_PLL4MHZ;

	wire DATASEP_MASTER_CLK;
	assign DATASEP_MASTER_CLK = CLK_PLL4MHZ;

	// Data separator
	wire SHAPED_DATA, DWIN;
	DataSeparator _datasep(DATASEP_MASTER_CLK, FD_RDDATA_IN, 
SHAPED_DATA, DWIN);

	// For debugging -- REMOVEME!
	assign debug[3:0] = { DATASEP_MASTER_CLK, FD_RDDATA_IN, 
SHAPED_DATA, DWIN };

  debug[3:0] is a set of output pins, CLK40MHZ is the master clock, 
CLK_PLL16MHZ is the output from the PLL. I can post the data separator 
logic as well, but it's basically a Verilog implementation of the circuit 
shown here:
  <http://www.analog-innovations.com/SED/FloppyDataExtractor.pdf>

  And this works fine on its own. I'm aware that there are issues with 
glitches if I just use a straight multiplexer to switch between clock 
sources, so I'm using the parameterised "clock_mux" module from the 
Quartus manuals
(<http://www.altera.com/literature/hb/qts/qts_qii51007.pdf>, chapter 6, 
page 48-50). I added it to my code like this (replacing the 
DATASEP_MASTER_CLK assignments in the code above):

	// Mux the clock
	wire DATASEP_MASTER_CLK;

	// Clock multiplexer
	wire [3:0] datasep_clock_selects = {
		(ACQCON_MFM_CLKSEL == 2'b00),
		(ACQCON_MFM_CLKSEL == 2'b01),
		(ACQCON_MFM_CLKSEL == 2'b10),
		(ACQCON_MFM_CLKSEL == 2'b11)  };
	wire [3:0] datasep_clocks = {	
		(CLK_PLL16MHZ),		// 3.5in ED (1Mbps)
		(CLK_PLL8MHZ),		// 3.5in HD (500kbps)
		(CLK_PLL4MHZ),		// 3.5in DD (250kbps)
		(CLK_PLL4MHZ)  };	// Dummy entry for SEL=0b11

	clock_mux #(.num_clocks(4)) _datasep_clock_mux(
						datasep_clocks,
						datasep_clock_selects,
						DATASEP_MASTER_CLK
					);

  This results in a ton of timing violation warnings from the timing 
analyser, the most notable being these two:

Warning: Can't achieve minimum setup and hold requirement 
DatasepClockGen:dscg|altpll:altpll_component|_clk0 along 9 path(s). See 
Report window for details.

Critical Warning: Timing requirements for slow timing model timing 
analysis were not met. See Report window for details.

  Obviously the setup/hold violation is not a "Good Thing (tm)" and it 
needs resolving ASAP (assuming the design works at all as it is). The 
question is, how should I go about doing this?

  I can replace the clock multiplexer with a straight AND/OR multiplexer, 
which seems to resolve the timing issue (or it did last time I tried it), 
but this risks causing glitching issues (although the Datasep should 
reset within about 64 clock cycles).

  Can anyone suggest a possible solution? This is driving me nuts... 
probably because the errors from Quartus are about as clear as a pool of 
mud, and it seems the Quartus "help" file is only serving to make the mud 
thicker...

Thanks,
-- 
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.

Article: 144291
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues
From: Michael S <already5chosen@yahoo.com>
Date: Wed, 25 Nov 2009 01:51:00 -0800 (PST)
Links: << >>  << T >>  << A >>
The solution is so simple it is not even funny.
1. clk_40Mhz => PLL => clk_32Mhz
2. clk_32Mhz => binary counter => (clk_4Mhz, clk_8Mhz, clk_16Mhz)
3. (clk_4Mhz, clk_8Mhz, clk_16Mhz) => regular mux (do not use
clock_mux!) => clk_temp
4. clk_temp => DFF with clk=clk_32Mhz => clk_out

Article: 144292
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Wed, 25 Nov 2009 10:27:04 -0000
Links: << >>  << T >>  << A >>
>  So I figured I'd go about this a different way -- generate a 16MHz
> clock with the PLL, then divide it down to 8MHz and 4MHz with a pair of
> DQ flip-flops wired to toggle (or a binary counter, whatever worked).


Noooooooo.

Generate your 16 MHz clock then use this to drive everything with enable
signals to give 8 and 4 MHz.

You're then just selecting the active enable signal to get the clock you want.

All nice and synchronous, don't generate ripple clocks etc.



Nial. 



Article: 144293
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Claytong_nz <clayton@isnotcrazy.com>
Date: Wed, 25 Nov 2009 03:30:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 25, 3:56=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 24 Nov 2009 07:47:47 -0800 (PST), austin <aus...@xilinx.com>
> wrote:
>
> >Jonathon,
>
> >CPLDs will fry themselves in space (latchup and die).
>
> >This is well known in the aerospace community: =A0do not put a CPLD in
> >space!
>
> OK, didn't realize he was planning to fly the thing :-)
> --
> Jonathan

Thanks Jonathan,

These FPGAs are apparently okay in low earth orbit. My understanding
is that they are already up there and working fine - at least the
older technologies such as this part (the rule for this project seems
to be that unless it is obsolete we won't use it). Retrofitting a new
device would not be the way to go!
Our design is based on an existing (and in orbit) design, but we are
now hand-tied by ITAR - hence the US guys are not permitted to help
us.
The PCB is all done but we've found this bug in the CPLD, so selecting
a different one is not an option.
The part is the 68pin PLCC. I'll follow up other leads, but if you are
still willing and able I'd like to take you up on your programmer
offer (or possibly purchasing it). Possibly I'll see if I can get
someone from the amateur radio statelite community that is closer to
you to assist. BTW, where are you?

Regards
Clayton


Article: 144294
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 25 Nov 2009 15:10:37 +0100
Links: << >>  << T >>  << A >>
On Wed, 25 Nov 2009 03:30:36 -0800 (PST), Claytong_nz wrote:

>These FPGAs are apparently okay in low earth orbit. My understanding
>is that they are already up there and working fine - at least the
>older technologies such as this part 

yeah, I guess they are fairly bulletproof (antifuse, 0.18um, ...)

>now hand-tied by ITAR - hence the US guys are not permitted to help

sheesh!

>I'd like to take you up on your programmer offer 

I'd be happy to see it go to a good home; I don't see myself ever
using it again.  You get three or four 12x16B 84PLCC thrown in :-)
And I'll try to find my archived copy of the software, but 
no promises on that; I haven't used it for years.

> (or possibly purchasing it)

Nah, you can have it - but we need to find a shipment method
that doesn't cost me anything, and doesn't cost you very much.

>BTW, where are you?

Oxford, England - but working in Munich, Germany for much of
the next few weeks.
-- 
Jonathan Bromley, Verification Engineer

Verilab   www.THAT_COMPANY.com

Article: 144295
Subject: Re: Going mad trying to solve PLL setup/hold timing violation
From: Philip Pemberton <usenet09@philpem.me.uk>
Date: 25 Nov 2009 18:57:47 GMT
Links: << >>  << T >>  << A >>
On Wed, 25 Nov 2009 01:51:00 -0800, Michael S wrote:

> The solution is so simple it is not even funny. 1. clk_40Mhz => PLL =>
> clk_32Mhz
> 2. clk_32Mhz => binary counter => (clk_4Mhz, clk_8Mhz, clk_16Mhz) 3.
> (clk_4Mhz, clk_8Mhz, clk_16Mhz) => regular mux (do not use clock_mux!)
> => clk_temp
> 4. clk_temp => DFF with clk=clk_32Mhz => clk_out

That works about as well as my original code...


	// Instantiate a PLL to convert from 40MHz to 32MHz
	wire CLK_PLL32MHZ;
	DatasepClockGen dscg(CLK40MHZ, CLK_PLL32MHZ);

	// Divide down the 32MHz reference to get 16MHz, 8MHz and 4MHz
	reg [2:0] DatasepClkDiv;
	always @(posedge CLK_PLL32MHZ) DatasepClkDiv <= DatasepClkDiv + 1;

	// Clock multiplexer
	reg DATASEP_CLK_pre;
	always @(ACQCON_MFM_CLKSEL or DatasepClkDiv) begin
		case (ACQCON_MFM_CLKSEL)
			2'b00:		DATASEP_CLK_pre = DatasepClkDiv
[0];
			2'b01:		DATASEP_CLK_pre = DatasepClkDiv
[1];
			2'b10:		DATASEP_CLK_pre = DatasepClkDiv
[2];
			default:	DATASEP_CLK_pre = DatasepClkDiv
[0];
		endcase
	end
	
	// Sync clock against 32MHz master clock to remove glitches
	reg DATASEP_MASTER_CLK;
	always @(posedge CLK_PLL32MHZ) DATASEP_MASTER_CLK <= 
DATASEP_CLK_pre;


produces:


Warning: Can't achieve minimum setup and hold requirement 
DatasepClockGen:dscg|altpll:altpll_component|_clk0 along 1 path(s). See 
Report window for details.

Critical Warning: Timing requirements for slow timing model timing 
analysis were not met. See Report window for details.


So the same problem as before, basically...

Thanks,
-- 
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.

Article: 144296
Subject: 32KHz RTC for FPGA
From: whygee <yg@yg.yg>
Date: Wed, 25 Nov 2009 21:22:46 +0100
Links: << >>  << T >>  << A >>
hello,

I woud like to design a 32,768 Hz stable input for
calibrated real-time operation of a FPGA-centric system,
as power-of-two frequencies make digital computations
very easy, using shifts instead of divides for motion equations.

  * I "could" use a multiple of this frequency as my
main clock but I find no suitable canned oscillator
(a 3.3V 5x7mm one is preferred, cheaper is better)

examples :
  - 18.423MHz / 32768 = 562.5 => almost there...
  so I would have to divide it by 5*5*5*3*3
   to get a power-of-two frequency, but only 16KHz.
  - 24.576MHz (close to my target 25MHz) = 2*3*5*5*5 * 32768
   so I get a nice 65536Hz after 4 small prescalers
   but my other 25MHz circuits won't be happy by 1.7%.
And I have already bought the 25MHz oscillators :-/

  * I "could" make a custom oscillator with a cheap&tiny "wristwatch"
cristal but the power consumption, stability and acuracy
would not be optimised.

  * My target is the Actel A3P250 in TQFP100 package.
I "could" use his Fusion sibling (that has an integrated
and separately powered RTC oscillator) but the price
difference is ... not enchanting. And the package is different.
And I have the A3P250 already :-/

  * I "could" use a common external I2C clock/calendar
but i'd prefer SPI and the cheap chips don't (rarely ?) provide
the 32KHz output (that I reuse to sequence stuff).

So... what's left ?

yg
--
http://ygdes.com / http://yasep.org

Article: 144297
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Claytong_nz <clayton@isnotcrazy.com>
Date: Wed, 25 Nov 2009 13:16:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 26, 1:10=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 25 Nov 2009 03:30:36 -0800 (PST), Claytong_nz wrote:
> >These FPGAs are apparently okay in low earth orbit. My understanding
> >is that they are already up there and working fine - at least the
> >older technologies such as this part
>
> yeah, I guess they are fairly bulletproof (antifuse, 0.18um, ...)
>
> >now hand-tied by ITAR - hence the US guys are not permitted to help
>
> sheesh!
>
> >I'd like to take you up on your programmer offer
>
> I'd be happy to see it go to a good home; I don't see myself ever
> using it again. =A0You get three or four 12x16B 84PLCC thrown in :-)
> And I'll try to find my archived copy of the software, but
> no promises on that; I haven't used it for years.
>
> > (or possibly purchasing it)
>
> Nah, you can have it - but we need to find a shipment method
> that doesn't cost me anything, and doesn't cost you very much.
>
> >BTW, where are you?
>
> Oxford, England - but working in Munich, Germany for much of
> the next few weeks.
> --
> Jonathan Bromley, Verification Engineer
>
> Verilab =A0www.THAT_COMPANY.com

Thank you. Your offer is very much appreciated Jonathan. I'll see if
we can find someone local to you to collect or some other arrangement.

Clayton

Article: 144298
Subject: Re: Going mad trying to solve PLL setup/hold timing violation
From: Philip Pemberton <usenet09@philpem.me.uk>
Date: 25 Nov 2009 21:24:53 GMT
Links: << >>  << T >>  << A >>
Sorted it...

I found this article a few hours ago:
<http://www.fpga-site.com/kiss.html>
... and just got around to reading it. That got me thinking... maybe it's 
the data-separator that's upsetting the timing analyser, not the clock 
divider.

So I started looking for gated clocks in the separator -- turns out the 
Data Window flip-flop is wired to toggle (i.e. divide its clock by two; 
not-Q wired to D), and is clocked from the most significant bit of the 
DPLL shift register...

module DataSeparator(MASTER_CLK, FD_RDDATA_IN, SHAPED_DATA, DWIN);

	input				
MASTER_CLK;			// Master Clock -- Data rate * 16
	input				FD_RDDATA_IN;		// L->H 
on flux transition
	output				SHAPED_DATA;		// 
Reshaped data pulses
	output				
DWIN;				// Data Window

/////////////////////////////////////////////////////////////////////////////
// "Phase-jerked loop" data separator
// Designed by James Thompson, Analog Innovations, Phoenix AZ.
// Verilog implementation by Phil Pemberton

	// Declare flipflops
	reg u2a, u2b;

	// U2A -- first synchroniser.
	wire u2a_nPreset = u2b;
	always @(posedge FD_RDDATA_IN or negedge u2a_nPreset) begin
		if (!u2a_nPreset) begin
			u2a <= 1'b1;
		end else begin
			u2a <= 1'b0;
		end
	end

	// U2B -- second synchroniser
	wire u2b_clk = !MASTER_CLK;
	always @(posedge u2b_clk) begin
		u2b <= u2a;
	end
	
	// U4A -- provides SHAPED_DATA
	reg SHAPED_DATA;
	always @(posedge u2b_clk or negedge u2b) begin
		if (!u2b) begin		// clear
			SHAPED_DATA <= 1'b0;
		end else begin
			SHAPED_DATA <= u2b;		// clock; D=u2b's 
output
		end
	end
	
	// PJL shift register
	reg [7:0] pjl_shifter;
	always @(posedge MASTER_CLK or negedge u2b) begin
		if (!u2b) begin
			// Asynchronous CLEAR
			pjl_shifter <= 8'b0000_0000;
		end else begin
			// Clock
			pjl_shifter <= {pjl_shifter[6:0], !pjl_shifter
[7]};
		end
	end
	
	// PJL output register
	reg DWIN;
	always @(posedge pjl_shifter[7]) begin
		DWIN <= ~DWIN;
	end
endmodule


A closer look in the timing report showed the path... clk0 output of the 
PLL to the MSB of the shifter. Hm.

I've rewritten the last block like this:

	// Latch the state of the SR output
	reg srout;
	always @(posedge MASTER_CLK) begin
		srout <= pjl_shifter[7];
	end
	
	// PJL output register
	reg DWIN;
	always @(posedge srout) begin
		DWIN <= ~DWIN;
	end

So now the output is clocked from the master clock, thus making most of 
the data separator synchronous (the only exception I can see is the first 
input synchronisation FF, U2A), and eliminating the timing issue.

But now I'm wondering if there's a better way to do this... I've got a 
design for a state machine based data separator from a Western Digital 
application note[1], but it suffers from a similar issue -- a DQ f/f 
wired to toggle, clocked from the MSB output of the state machine PROM.

Making sense of the logic behind either the Analog Innovations "shift 
register DPLL" isn't too hard once you start stepping it through, but the 
WD one is an utter beast... And they very helpfully didn't bother 
documenting it beyond saying "figure 12 shows a data separator built 
around a state machine" and providing a ROM dump :-/

[1] "FD179x Application Notes". Western Digital, June 1980; p. 12, 
"Figure 12: 179x Data Separator." <http://www.bitsavers.org/pdf/
westernDigital/FD179X_Application_Notes_Jun80.pdf>

Thanks,
-- 
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.

Article: 144299
Subject: Re: 32KHz RTC for FPGA
From: -jg <jim.granville@gmail.com>
Date: Wed, 25 Nov 2009 13:28:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 26, 9:22=A0am, whygee <y...@yg.yg> wrote:
>
> So... what's left ?

It's not clear exactly what you are asking ?

Epson, EM Microelectronic et al, have 32Khz osc
modules, that include the crystal.

Maxim have one that is TCXO as well, and
if precision matters, then you will need txco.

NXP PCF2129 is another candidate, but less stocked.

MicroCrystal.com also have a range.

Some tcxo's are fixes in time, not frequency, so
watch the details ;)

-jg






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