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 112125

Article: 112125
Subject: Re: Problems with Opencores' I2C "READ" function
From: "markus" <markus_1401@yahoo.com>
Date: 16 Nov 2006 12:24:52 -0800
Links: << >>  << T >>  << A >>
Hi Mark,

Thanks for your comment.

Is the waiting for TIP and ack an "and" function i.e. both must be
deasserted before proceeding to the next step? Is the ack you are
referring to is the ack from Status Register bit 7 or  from wb_ack_o?

Thanks,
-M

Mark McDougall wrote:
> markus wrote:
>
> > I am wondering if any of you have encountered a problem in which the
> > Opencores' I2C "READ" function failed.
>
> I've successfully used the core on 2 different designs...
>
> > In order to initiate a read sequence, I first sent a write to the
> > slave, followed by the memory address location of the slave's register,
> > then I sent the read instruction. I checked whether wb_ack_o pin is
> > asserted and that the TIP signal have been negated before proceeding
> > from one command to another. Is there something else that I need to do
> > prior to executing from one command to another (i.e. more pauses?)? Or
> > do I need to turn on clock stretching? I thought the clock stretching
> > is supported automatically.
>
> Here's the sequence I use to read a byte...
>
> // device address and dummy write
> WR(TXR,{dev,0})
> WR(CR,STA|WR)
> wait for not tip and ack
> // memory address
> WR(TXR,addr)
> WR(CR,WR)
> wait for not tip and ack
> // start reading
> WR(TXR,{dev,1})
> WR(CR,STA|WR)
> wait for not tip and ack
> WR(CR,RD|ACK|STO)
> wait for not tip
> RD(RXR)
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266


Article: 112126
Subject: Re: how to filter glitches and mutliple transitions?
From: PeteS <peter.smith8380@ntlworld.com>
Date: Thu, 16 Nov 2006 20:25:06 GMT
Links: << >>  << T >>  << A >>
John McGrath wrote:
> I assume, because we are talking about glitches, that changes in Sig
> are effectively asynch to the clk - so shouldn't it be synchronised
> with a 2 flip-flop synchronizer first, or else the counter could count
> incorrectly? (some flip-flops seeing the value as a 1, others seeing it
> as a 0 ) perhaps the nature of the system means it can recover from
> that, but I think it would make it safer.
> (I've had a few glasses of wine too, so the same disclaimer for me!)
> Cheers
> John
> 
> PeteS wrote:
>> A small fix :)
>>
>> PeteS wrote:
>>> Frank Buss wrote:
>>>> I have built a prototyp board with wires between the FPGA and an external
>>>> component. With the scope I can see glitches (looks like from crosstalk
>>>> when switching other signals) and multiple transitions are detected by
>>>> the
>>>> FPGA when switching signals. Looks like the noise is < 200 ns. The period
>>>> of the wanted signal is > 3 us. I think with a PCB there would be less
>>>> problems, but there is lots of space left inside the FPGA, so it
>>>> should be
>>>> possible enhance the signal with logic so that it works even with the
>>>> noisy
>>>> wired prototype. What do you do normally to solve this kind of problems?
>>>>
>>>> My idea is to use a low-pass filter: a n bit counter, which is
>>>> incremented
>>>> with system clock, if the input signal is 1 and decremented otherwise. If
>>>> all n bits are 1, the counter is not incremented and if all bits are
>>>> 0, it
>>>> is not decremented. If the highest bit is set, then the sampled signal is
>>>> considered as 1, otherwise as 0. I could encapsulate this function
>>>> within a
>>>> VHDL entity, so it is easy to use it for multiple input signals and
>>>> maybe a
>>>> generic for specifying n.
>>>>
>>> Hi Frank
>>>
>>> You are describing a soft filter.
>>>
>>> I have a number of them in a current design (it's in a rather noisy
>>> environment) and I use a 5 bit counter as part of a state machine.
>>>
>>> I assume you have an appropriate clock, so simply qualify the signal as
>>> continuously present (or perhaps mostly present) for the 3us you state.
>>>
>>> With a 10MHz clock, for example, a 5 bit counter is almost perfect (and
>>> besides, we can always terminate at count = 30 ;)
>>>
>>> I like your approach, but this is simple and uses pretty limited resources.
>>>
>>> so, somewhere
>>>
>>> wire Sig; // the signal we are watching
>>> reg SigValid; // valid indicator
>>> reg [4:0] SigCount;
>>>
>>>
>>> always @(posedge clk)
>>> begin
>>> if (!Sig)
>>> begin
>>>     SigCount <= 5'b00000; // signal disappeared, clear counter
>>>     SigValid <= 1'b0;
>>> end
>>> else if(Sig & SigCount < 28)
>>> begin
>>>     SigCount <= SigCount+1;
>>>
>>> end
>> // fix the next line
>> // was else if (SigCount == 28)
>>   else if (Sig & SigCount == 28)
>>
>> // qualify signal properly
>>
>>> begin
>>>     SigValid <= 1'b1; // Signal has been true for 30
>>> consecutive                       // clocks.
>>> end
>>> end
>>>
>>> Simple, as I said, and if you find bugs, I state in my defence I have
>>> had a couple of glasses of wine :)
>>>
>>>
>>> Cheers
>>>
>>> PeteS
> 

Well, in this case, I have a 5 flipflop synchroniser :)

Cheers

PeteS

Article: 112127
Subject: Re: how to filter glitches and mutliple transitions?
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 16 Nov 2006 21:30:07 +0100
Links: << >>  << T >>  << A >>
Frank Buss wrote:

> entity low_pass_filter is
> 	generic(
> 		counter_max: positive := 30;
> 		hysteresis: positive := 5);

Some corrections: hysteresis doesn't make sense. I've deleted it and tested
in low-state for counter=counter_max and in high-state for counter=0 and
tested it today with real hardware and it works.

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

Article: 112128
Subject: Re: how to filter glitches and mutliple transitions?
From: PeteS <peter.smith8380@ntlworld.com>
Date: Thu, 16 Nov 2006 20:33:15 GMT
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> Frank Buss wrote:
> 
>> entity low_pass_filter is
>> 	generic(
>> 		counter_max: positive := 30;
>> 		hysteresis: positive := 5);
> 
> Some corrections: hysteresis doesn't make sense. I've deleted it and tested
> in low-state for counter=counter_max and in high-state for counter=0 and
> tested it today with real hardware and it works.
> 

Well, good!

If talking through a problem helps you solve it, only too glad to talk :)

Cheers

PeteS

Article: 112129
Subject: Re: Old Spartan-II, worth prototyping?
From: "Leon" <leon.heller@bulldoghome.com>
Date: 16 Nov 2006 13:12:29 -0800
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> John,
>
> Right you are.  Spartan 2 is like "classic Coca-Cola", it is really hard
> to improve upon.
>
> Even the original Spartan (4KXLA derivative) is still going strong.

Another advantage is that they are available in PLCC, I've got a tube
of them somewhere.

Leon


Article: 112130
Subject: Re: 8080 FSGA model in an FPGA
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Thu, 16 Nov 2006 15:18:17 -0600
Links: << >>  << T >>  << A >>


PeteS wrote:

>
> I seem to recall from the distant past that the 8080 (some versions) 
> used depletion load; i.e. a depletion mode device with gate tied to 
> source instead of a resistive load. Not that it reduces the components 
> (an in fact adds a pin per active transistor).
>
So do these depletion loads count in the 8000 transistors?  Then, the 
8080 function could
maybe be performed by 4000 active devices and 4000 resistors.  (Im sort 
of thinking that
it was 8000 amplifying transistors in the count, 4000 just seems too 
low, as you'd need
2 for every FF, and the 8080 actually had a lot of registers, for the time.)

Jon


Article: 112131
Subject: Re: 8080 FSGA model in an FPGA
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Thu, 16 Nov 2006 15:19:11 -0600
Links: << >>  << T >>  << A >>


logjam wrote:

>>we have 6000 times 5 components (2 diodes, 2 res, one trans) = 30,000
>>components.
>>Does this still sound practical?
>>    
>>
>
>Not practical, but fun!  I have a 88x40 inch display made out of 19,008
>T 1 3/4 LEDs for example...  ;)
>
>  
>
>>Anyway, it should be fairly easy to design the CPU for FPGA implementation.
>>I'd forget the TTL component emulation, and use either VHDL or Verilog,
>>or maybe
>>one of the RTL synthesis tools.  These are able to specify a CPU very
>>concisely.
>>    
>>
>
>Would there be a simple way of generating some sort of human
>understandable information that would help generate a schematic?
>  
>
Yes, RTL was used as a descriptive tool for YEARS before there ever was 
a synthesis
tool that accepted it.

Jon


Article: 112132
Subject: Maximum Operating Frequency
From: "terabits" <tera.bits@gmail.com>
Date: 16 Nov 2006 13:35:49 -0800
Links: << >>  << T >>  << A >>
Hi

On what factors the maximum operating frequency of ahb master and slave
depends ?
in general what is the maximum frequency we can go for ?

regards


Article: 112133
Subject: Re: Compiling Linux Kernel for ML405
From: "funkrhythm" <funkrhythm@gmail.com>
Date: 16 Nov 2006 13:54:51 -0800
Links: << >>  << T >>  << A >>

edit arch/ppc/platforms/xilinx_ocp/xilinx_syms.c
and change references to XpacketFifoV100a -> XpacketFifoV200a
(there's an include file and 4 EXPORT_SYMBOLs)

Peter Mendham wrote:
> Dear all,
>
> I'm trying to build a straightforward Linux Kernel for the Xilinx ML405
> board and I'm running into one small problem.  The build gets most of
> the way through and fails at link stage, missing a crucial function.
> The function in question is part of the Xilinx OCP BSP in the file
> xpacket_fifo_v2_00_a.c  Tracing make, as best I can, this file never
> gets built.  The only code that uses the function is in a driver and
> hence only "meets up" with the functions at final link time, which is
> where the problem arises.
>
> Now, I'm certainly not a make guru, so I don't really understand how
> make calculates the dependencies during make dep (all these .depend
> files) and I'm not sure how make then uses these to build the required
> output files.  How do I coax make into building the missing file(s)?
> Does anyone have any experience building kernels for the ML405?
>
> I'm building a PPC development 2.4 downloaded using bitkeeper.  I'm
> (mostly) following the instructions here:
> http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm which are
> for the ML403, but close enough.
> 
> Any help - however small - would be great.
> 
> TIA,
> 
> -- Peter


Article: 112134
Subject: Warnings in Xilinx 8.2i
From: "learnfpga" <learnfpga@gmail.com>
Date: 16 Nov 2006 14:11:55 -0800
Links: << >>  << T >>  << A >>
I am new to CPLD's and I am trying to make a new design incorporating
some of the old abel code. I am using schematic entry (XC9572). I have
converted the abel code into symbols and incorporating them to my
schematic. In the new design I am not using many of the input and
outputs that were defined in the abel code but I dont want to fiddle
with that and so I am using the code as it is.

Now when I synthesize I get following warnings..

WARNING:Xst:647 - Input <A00> is never used.

WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used.

WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a
combinatorial loop: _xor0004, BEL, _xor0002

WARNING:Xst:1354 - Port SPAREI is not connected, attached property
removed (LOC)


Should I worry about these warnings because I am not using all these
ports/signals/input?

At present I have connected all unused inputs to ground and left the
unused outputs as it is. Is that the right approach?

Thanks for any responses...


Article: 112135
Subject: Validity of data on rising edge of clock
From: "nfirtaps" <lloyd.rochester@gmail.com>
Date: 16 Nov 2006 14:35:01 -0800
Links: << >>  << T >>  << A >>
It seems to be annoying to have my data valid on the rising edge of a
clock internal to the FPGA.  If I have a process that has logic on the
rising edge of a clock that generates or processes some sort of data,
and another process that samples this data, to say put into a memory
buffer.  What are you guys doing in order to skew the clock out of
phase so it samples the data on the rising edge of this clock?  For
example if you have

process(clk)
begin
 if(clk'event and clk='1') then
    some_array(some_index) <= data;
 end if;
end process;

and ....

process(clk)
begin
 if(clk'event and clk='1') then
    data <= data+1;
 end if;
end process;

This will have a horrible outcome because the data is not valid on the
rising edge?  Right?  What is a nice way to get around this?  Besides
using things like clock managers?


Article: 112136
Subject: Re: Validity of data on rising edge of clock
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 16 Nov 2006 14:52:56 -0800
Links: << >>  << T >>  << A >>

nfirtaps wrote:
> It seems to be annoying to have my data valid on the rising edge of a
> clock internal to the FPGA.

It's valid for the entire clock cycle AFTER the leading edge...

>  If I have a process that has logic on the
> rising edge of a clock that generates or processes some sort of data,
> and another process that samples this data, to say put into a memory
> buffer.  What are you guys doing in order to skew the clock out of
> phase so it samples the data on the rising edge of this clock?

Using standard logic design techniques that have been in existence for
decades.  You're not grasping the fact that any flip flop changes state
only AFTER the rising edge of the clock....which is exactly what your
processes say as well.

> For
> example if you have
>
> process(clk)
> begin
>  if(clk'event and clk='1') then
-- KJ: You won't get here until AFTER the rising edge of the clock.
>     some_array(some_index) <= data;
>  end if;
> end process;
>
> and ....
>
> process(clk)
> begin
>  if(clk'event and clk='1') then
-- KJ: You won't get here until AFTER the rising edge of the clock.
>     data <= data+1;
>  end if;
> end process;
>
> This will have a horrible outcome because the data is not valid on the
> rising edge?
Sure it's valid, it won't start to change until AFTER the rising edge
but it get sampled on what is there right AT the rising edge...not
after, not before.  The only 'difference' between simulation and real
world flip flops is that a real world device will have a propogation
delay specified in nanoseconds whereas the simulation environment the
delay will be one simulation delta cycle.

> Right?
Wrong.

> What is a nice way to get around this?  Besides
> using things like clock managers?

Design using standard synchronous design techniques.  In fact the two
processes you've shown will do exactly what you want them to do; there
will be a two clock cycle latency between when 'data' first switches
and when the memory gets updated, but that's exactly what you specified
that you wanted which is also the way that most people would go about
doing what you appear to want.  You wouldn't use any sort of 'clock
manager' or anything else to skew the clock either.

KJ


Article: 112137
Subject: Re: Validity of data on rising edge of clock
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 16 Nov 2006 15:05:50 -0800
Links: << >>  << T >>  << A >>
nfirtaps wrote:
> It seems to be annoying to have my data valid on the rising edge of a
> clock internal to the FPGA.  

Synchronous data is valid for a long time before
the rising clock edge, but only for a short time
after the edge. I am always sampling the
"old" value, so what happens during the clock
to Q change does not really matter.

       -- Mike Treseler



Article: 112138
Subject: Re: Warnings in Xilinx 8.2i
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 17 Nov 2006 12:14:20 +1300
Links: << >>  << T >>  << A >>
learnfpga wrote:
> I am new to CPLD's and I am trying to make a new design incorporating
> some of the old abel code. I am using schematic entry (XC9572). I have
> converted the abel code into symbols and incorporating them to my
> schematic. In the new design I am not using many of the input and
> outputs that were defined in the abel code but I dont want to fiddle
> with that and so I am using the code as it is.
> 
> Now when I synthesize I get following warnings..
> 
> WARNING:Xst:647 - Input <A00> is never used.
> 
> WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used.
> 
> WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a
> combinatorial loop: _xor0004, BEL, _xor0002
> 
> WARNING:Xst:1354 - Port SPAREI is not connected, attached property
> removed (LOC)
> 
> 
> Should I worry about these warnings because I am not using all these
> ports/signals/input?
> 
> At present I have connected all unused inputs to ground and left the
> unused outputs as it is. Is that the right approach?
> 
> Thanks for any responses...

Check the fitter report files, they will show you what _actually_
happened.

Why design in schematic, if you already have the code in abel ?.
AFAIK Xilinx still supports that flow fine for CPLDs.

-jg



Article: 112139
Subject: Re: XCF02S + Spartan 2e JTAG config problems
From: "Gabor" <gabor@alacron.com>
Date: 16 Nov 2006 15:25:32 -0800
Links: << >>  << T >>  << A >>

Antti wrote:
> Gabor schrieb:
>
> > I'm seeing some strange behavior when trying to program
> > a Spartan 2e (XC2S150E) directly via JTAG.  In the system
> > it is normally programmed using master serial mode from
> > the XCF02S "platform flash" part.  The JTAG chain starts
> > with the XCF02S and then ends at the XC2S150E - no
> > other parts.  I can program the XCF02S without problem
> > using JTAG.  I can also program the XC2S150E without
> > problems via JTAG _IF_ the XCF02S is blank.  Once the
> > FPGA has been programmed from the XCF02S using
> > master serial mode, which is the normal case after
> > power-up, attempts to re-program the FPGA using JTAG
> > fail.  This does not seem to be a problem with the
> > FPGA running.  I can re-program the FPGA via JTAG
> > when it is running _IF_ the FPGA was originally configured
> > via JTAG.  I have opened a web case on this, but I thought
> > someone here may have some insight on this issue.  I
> > saw in an old thread the following note:
> >
> > David Kinsell wrote:
> >
> > We've seen different problems with an XCF02S in the chain ahead of a
> > Spartan 2 part.  Done never goes high on the Spartan when attempting
> > JTAG programming.  Take the XCF02 out of the chain and it works.
> > Discovered that if the XCF02 is blank, then we can program the Spartan
> > OK.  Xilinx has some answer records (18644 and others) on related
> > issues, but that didn't seem to apply to us.
>
> this issue can cause problems for different parts, no matter if there
> is an Xilinx AR or not
>
> the thing is that if any non-JTAG config interface shifts in valid SYNC
> word
> during some specifig time in the JTAG config process then the JTAG
> configuration will fail.
>
> happens with XCFxx master serial mode, happens with Se3 BPI mode (at
> least early silicon)
> etc, etc..
>
> so just make sure the config is blank
>
> antti

Thanks, Antti.

I was hoping this wasn't the answer.  The current hardware revision in
the
field requires the FPGA to boot from the XCF02S in order to provide a
clean reset signal to an embedded processor.  There is no way for the
processor to boot up and program the FPGA in these boards if the FPGA
isn't already running some version.  In order to change this behavior
I need wiring changes to the boards, and using wires I have a lot
of possible ways to work around the issue.  It would have been nice
to fix this in "software" only.  Right now my only "software" solution
is to re-program the XCF02S if I want to upgrade the FPGA bitstream.
If this process gets interrupted I would end up with a non-working
system. :-(

Regards,
Gabor


Article: 112140
Subject: Re: how to filter glitches and mutliple transitions?
From: "John McGrath" <tails4e@gmail.com>
Date: 16 Nov 2006 17:43:53 -0800
Links: << >>  << T >>  << A >>
Except the asynch control signal is going to all 5 flip-flops at the
same time, which means if it came at just the wrong time, some would
capture it, and others would not - causing unexpected behaviour. in a
real synchronizer, the asynch signal only goes to one flip-flop.

PeteS wrote:
> John McGrath wrote:
> > I assume, because we are talking about glitches, that changes in Sig
> > are effectively asynch to the clk - so shouldn't it be synchronised
> > with a 2 flip-flop synchronizer first, or else the counter could count
> > incorrectly? (some flip-flops seeing the value as a 1, others seeing it
> > as a 0 ) perhaps the nature of the system means it can recover from
> > that, but I think it would make it safer.
> > (I've had a few glasses of wine too, so the same disclaimer for me!)
> > Cheers
> > John
> >
> > PeteS wrote:
> >> A small fix :)
> >>
> >> PeteS wrote:
> >>> Frank Buss wrote:
> >>>> I have built a prototyp board with wires between the FPGA and an external
> >>>> component. With the scope I can see glitches (looks like from crosstalk
> >>>> when switching other signals) and multiple transitions are detected by
> >>>> the
> >>>> FPGA when switching signals. Looks like the noise is < 200 ns. The period
> >>>> of the wanted signal is > 3 us. I think with a PCB there would be less
> >>>> problems, but there is lots of space left inside the FPGA, so it
> >>>> should be
> >>>> possible enhance the signal with logic so that it works even with the
> >>>> noisy
> >>>> wired prototype. What do you do normally to solve this kind of problems?
> >>>>
> >>>> My idea is to use a low-pass filter: a n bit counter, which is
> >>>> incremented
> >>>> with system clock, if the input signal is 1 and decremented otherwise. If
> >>>> all n bits are 1, the counter is not incremented and if all bits are
> >>>> 0, it
> >>>> is not decremented. If the highest bit is set, then the sampled signal is
> >>>> considered as 1, otherwise as 0. I could encapsulate this function
> >>>> within a
> >>>> VHDL entity, so it is easy to use it for multiple input signals and
> >>>> maybe a
> >>>> generic for specifying n.
> >>>>
> >>> Hi Frank
> >>>
> >>> You are describing a soft filter.
> >>>
> >>> I have a number of them in a current design (it's in a rather noisy
> >>> environment) and I use a 5 bit counter as part of a state machine.
> >>>
> >>> I assume you have an appropriate clock, so simply qualify the signal as
> >>> continuously present (or perhaps mostly present) for the 3us you state.
> >>>
> >>> With a 10MHz clock, for example, a 5 bit counter is almost perfect (and
> >>> besides, we can always terminate at count = 30 ;)
> >>>
> >>> I like your approach, but this is simple and uses pretty limited resources.
> >>>
> >>> so, somewhere
> >>>
> >>> wire Sig; // the signal we are watching
> >>> reg SigValid; // valid indicator
> >>> reg [4:0] SigCount;
> >>>
> >>>
> >>> always @(posedge clk)
> >>> begin
> >>> if (!Sig)
> >>> begin
> >>>     SigCount <= 5'b00000; // signal disappeared, clear counter
> >>>     SigValid <= 1'b0;
> >>> end
> >>> else if(Sig & SigCount < 28)
> >>> begin
> >>>     SigCount <= SigCount+1;
> >>>
> >>> end
> >> // fix the next line
> >> // was else if (SigCount == 28)
> >>   else if (Sig & SigCount == 28)
> >>
> >> // qualify signal properly
> >>
> >>> begin
> >>>     SigValid <= 1'b1; // Signal has been true for 30
> >>> consecutive                       // clocks.
> >>> end
> >>> end
> >>>
> >>> Simple, as I said, and if you find bugs, I state in my defence I have
> >>> had a couple of glasses of wine :)
> >>>
> >>>
> >>> Cheers
> >>>
> >>> PeteS
> >
>
> Well, in this case, I have a 5 flipflop synchroniser :)
> 
> Cheers
> 
> PeteS


Article: 112141
Subject: Spartan 3/3E to Standard TTL/Low power devices
From: "Grant Stockly" <grant@stockly.com>
Date: 16 Nov 2006 17:57:37 -0800
Links: << >>  << T >>  << A >>
What would you guys recomend as a bus transciever for interfacing with
standard TTL and low power TTL logic?  I'm thinking that the TI
74AC11245 would work.  The high/low thresholds seem to be good and it
will tollerate 5v input on the bus side...

Thanks,
Grant


Article: 112142
Subject: Re: Spartan 3/3E to Standard TTL/Low power devices
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 17 Nov 2006 02:25:07 GMT
Links: << >>  << T >>  << A >>
Grant Stockly wrote:
> What would you guys recomend as a bus transciever for interfacing with
> standard TTL and low power TTL logic?  I'm thinking that the TI
> 74AC11245 would work.  The high/low thresholds seem to be good and it
> will tollerate 5v input on the bus side...
> 
> Thanks,
> Grant

The AC part isn't TTL.

True TTL has Vih=2.0V and Vil=0.8V levels which are entirely compatible 
with the 3.3V Vcco powered LVTTL IOSTANDARD.

If you're using a hybrid technology like ACT logic where the inputs are 
TTL compatible but the outputs are CMOS swing, simple series resistors 
will allow your 3.3V Vcco powered LVTTL inputs to deal with the high 
rails.  It might be "safer" to include those resistors with classic 5V 
powered TTL devices anyway.

The series resistor is a consideration if you're doing I/Os over long 
lines for high slew rate edges because the resistor value is much larger 
than the characteristic impedance of the circuit board trace.  Those are 
the only signals you have to pay closer attention to.

The appropriate resistor values and the data to back up the value 
selection are found in various pieces of the FPGA documentation.

Article: 112143
Subject: xsa-200 building a Mp3 player
From: "langjr15@uwgb.edu" <langjr15@uwgb.edu>
Date: 16 Nov 2006 18:41:22 -0800
Links: << >>  << T >>  << A >>
Hi all,

Im very new to XILINX development bubt for a class project we were
assigned the task of building a MP3 player.  We were given a decoder
and a mem-reader so we pretty much need to feed data to it and get the
output.  But Im not entirely sure how to read data from the onboard
memory.  Has anyone done sonething like this before?

Any help would be appreciated thanks - jon


Article: 112144
Subject: Re: Warnings in Xilinx 8.2i
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 17 Nov 2006 07:07:07 +0100
Links: << >>  << T >>  << A >>
Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag 
news:455cf081$1@clear.net.nz...
> learnfpga wrote:
>> I am new to CPLD's and I am trying to make a new design incorporating
>> some of the old abel code. I am using schematic entry (XC9572). I have
>> converted the abel code into symbols and incorporating them to my
>> schematic. In the new design I am not using many of the input and
>> outputs that were defined in the abel code but I dont want to fiddle
>> with that and so I am using the code as it is.
>>
>> Now when I synthesize I get following warnings..
>>
>> WARNING:Xst:647 - Input <A00> is never used.
>>
>> WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used.
>>
>> WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a
>> combinatorial loop: _xor0004, BEL, _xor0002
>>
>> WARNING:Xst:1354 - Port SPAREI is not connected, attached property
>> removed (LOC)
>>
>>
>> Should I worry about these warnings because I am not using all these
>> ports/signals/input?
>>
>> At present I have connected all unused inputs to ground and left the
>> unused outputs as it is. Is that the right approach?
>>
>> Thanks for any responses...
>
> Check the fitter report files, they will show you what _actually_
> happened.
>
> Why design in schematic, if you already have the code in abel ?.
> AFAIK Xilinx still supports that flow fine for CPLDs.
>
> -jg
>

Jim

this is a bug in ISE 8.x it only happens for 95xx CPLDs
IMHO the only solution is to use ISE 7.1 or 6.3 for XC95xx

Antti






Article: 112145
Subject: Hpw to remove combinational loops in quartus s/w
From: vsrpkumar@rediffmail.com
Date: 16 Nov 2006 22:30:04 -0800
Links: << >>  << T >>  << A >>
I have some combinational loops in my design.2 blocks are there with
interface .1 st block output is going to second one input. and vice
versa.problem is the pins of the blocks are dissappearing in the
postfitting of  design.How to constrain.I am using quartus s/w 6.0
version with cyclone II device


Article: 112146
Subject: Re: Synthesis size of Circuits?
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Fri, 17 Nov 2006 07:21:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2006-11-16, olson_ord@yahoo.it <olson_ord@yahoo.it> wrote:
> 	I hope you can tell me what is the size of the circuits that you guys
> synthesize? Am I trying something impossible here? - I thought 10K was
> a small size.  I would be glad to hear of any ideas you may have on how
> to get this to synthesize. I am not so much concerned about the run
> time - but that it works without crashing. 

If it turns up that your source code is too complicated to synthesize
with your current machine you could perhaps divide your design into
several files and compile each file separately. One keyword to search
for is incremental synthesis.


/Andreas

Article: 112147
Subject: Re: use boundary scan in spartan-3
From: "colin" <colin_toogood@yahoo.com>
Date: 17 Nov 2006 00:10:44 -0800
Links: << >>  << T >>  << A >>
What are you doing with TMS during this. Your post suggests you throw a
pattern at TDI and then expect data out of TDO.

Colin


Antti Lukats wrote:
> <florent.peyrard@gmail.com> schrieb im Newsbeitrag
> news:1163696998.857615.68930@h54g2000cwb.googlegroups.com...
> > Hi all,
> >
> > i'm new to boundary scan and want to make it work in the xilinx starter
> > board, which contains a spartan-3 FPGA (xc3s200) and a platform flash
> > PROM (xcF02s).
> >
> > i'd like to make just a simple test, independantly of any design, just
> > to become familiar with this protocol: monitor the value of one of the
> > 8 switches of the board. here is what i did: i entered an instruction:
> > 000001 11111111 to put the PROM in bypass mode and the fpga in SAMPLE
> > mode. then i shift data out but the expected value doen't appear on TDO
> > after the expected number of clock edges, it seems that the capture
> > state doesn't work. i've read that during configuration, I/Os are not
> > connected, maybe this is my problem: i intentionnally changed the
> > jumpers to prevent configuration otherwise once configured, boundary
> > scan features aren't available any more. but maybe the system stays in
> > configuration mode, waiting for configuration and disabling I/Os until
> > configuration is done...can you help about this fact?
> >
> > and if i give up and try to instantiate the BSCAN_SPARTAN3 component in
> > a design in order to make the boundary scan feature available after
> > configuration, i just don't undertand at all how to instantiate it:
> > what should i link the pins of the symbol to?
> >
> > thanks a lot in advance, i'm very interested in this technology and it
> > would be a shame to give up..
> >
> > florent
> >
>
> you are doing something wrong, boundary scan *IS* available before
> configuration and it works.
> 
> Antti


Article: 112148
Subject: Re: XCF02S + Spartan 2e JTAG config problems
From: "Antti" <Antti.Lukats@xilant.com>
Date: 17 Nov 2006 00:36:44 -0800
Links: << >>  << T >>  << A >>
Gabor schrieb:

> Antti wrote:
> > Gabor schrieb:
> >
> > > I'm seeing some strange behavior when trying to program
> > > a Spartan 2e (XC2S150E) directly via JTAG.  In the system
> > > it is normally programmed using master serial mode from
> > > the XCF02S "platform flash" part.  The JTAG chain starts
> > > with the XCF02S and then ends at the XC2S150E - no
> > > other parts.  I can program the XCF02S without problem
> > > using JTAG.  I can also program the XC2S150E without
> > > problems via JTAG _IF_ the XCF02S is blank.  Once the
> > > FPGA has been programmed from the XCF02S using
> > > master serial mode, which is the normal case after
> > > power-up, attempts to re-program the FPGA using JTAG
> > > fail.  This does not seem to be a problem with the
> > > FPGA running.  I can re-program the FPGA via JTAG
> > > when it is running _IF_ the FPGA was originally configured
> > > via JTAG.  I have opened a web case on this, but I thought
> > > someone here may have some insight on this issue.  I
> > > saw in an old thread the following note:
> > >
> > > David Kinsell wrote:
> > >
> > > We've seen different problems with an XCF02S in the chain ahead of a
> > > Spartan 2 part.  Done never goes high on the Spartan when attempting
> > > JTAG programming.  Take the XCF02 out of the chain and it works.
> > > Discovered that if the XCF02 is blank, then we can program the Spartan
> > > OK.  Xilinx has some answer records (18644 and others) on related
> > > issues, but that didn't seem to apply to us.
> >
> > this issue can cause problems for different parts, no matter if there
> > is an Xilinx AR or not
> >
> > the thing is that if any non-JTAG config interface shifts in valid SYNC
> > word
> > during some specifig time in the JTAG config process then the JTAG
> > configuration will fail.
> >
> > happens with XCFxx master serial mode, happens with Se3 BPI mode (at
> > least early silicon)
> > etc, etc..
> >
> > so just make sure the config is blank
> >
> > antti
>
> Thanks, Antti.
>
> I was hoping this wasn't the answer.  The current hardware revision in
> the
> field requires the FPGA to boot from the XCF02S in order to provide a
> clean reset signal to an embedded processor.  There is no way for the
> processor to boot up and program the FPGA in these boards if the FPGA
> isn't already running some version.  In order to change this behavior
> I need wiring changes to the boards, and using wires I have a lot
> of possible ways to work around the issue.  It would have been nice
> to fix this in "software" only.  Right now my only "software" solution
> is to re-program the XCF02S if I want to upgrade the FPGA bitstream.
> If this process gets interrupted I would end up with a non-working
> system. :-(
>
> Regards,
> Gabor

well there could be a software only solution, but you need to
investigate it I told what the cause, so you need to see if you can
bypass the issue

make a small CPLD that makes an LED "ON" when it sees FPGA config start
pattern being shifted in, attach it to CCLK and DIN then make your own
JTAG config software and single step it to program the FPGA and monitor
the LED, you might be able to find a sequence of JTAG commands that
work and succeed to configure the FPGA no matter if the XCF shifts out
the config SYNC at wrong place.

if you can gurantee deterministic timing of the JTAG config stream then
all you need may be just padding the XCF with dummy to align the SYNC
to a time slot where it does not harm the configuration.

or at very bottom end you may place XCF in EXTEST mode during the
config or at some short time during config to prevent it to trasht the
config.

so it may be doable but may take several weeks to work it out

Antti


Article: 112149
Subject: Re: Synthesis size of Circuits?
From: "Thomas Stanka" <usenet_10@stanka-web.de>
Date: 17 Nov 2006 00:58:55 -0800
Links: << >>  << T >>  << A >>

olson_ord@yahoo.it schrieb:
> circuits and synthesize them to the FPGAs. I read the circuits using
> the ISCAS benchmark format - made my changes to the circuit structure
> and dumped out the VHDL.
[..]

> for a 10K gate circuit - I had a little more than 10K entities. Note
> that I did not increase the number of gates - but I just added
> additional Muxs (multiplexers) and some control lines. I was surprised
> that this modified circuit would not synthesize.

The number of gates _will_ increase, if you add gates!
I guess you even didn't care about signal buffering. A signal driving
10k gates needs roughly 1000 gates for signal buffering.

> A code sample showing one of my gates (with the associated Mux) is
>
> 	Nand_2_0_0 : forg_node_16_Cell_0  <=  not (input_2_Cell_0 and
> node_11_Cell_0);
>
>
> 	SEL_node_16_Cell_0(1) <=  ctrl_fault_4_Cell_0;
> 	SEL_node_16_Cell_0(2) <=  ctrl_fault_5_Cell_0;

         node_16_cell_0 <= fault_4_node_16 when (insert_faults_cell_0 =
'1' and SEL_node_16_cell_0 = "01") else
                                    fault_5_node_16 when
(insert_faults_cell_0 = '1' and SEL_node_16_cell_0 = "10") else
                                    forg_node_16_cell_0;

could be a bit smaller code replacement for your mux (won't change
anything concerning synthesis) but you drastically reduce the number of
lines for same functionality.

> (Just imagine that I do this 10K times - including final signal
> mapping.)

This adds roughly 10k times 1 complex gate with 6 inputs and 1 output
to your design without any signal buffering, meaning you double your
gatecount at least. In fact I expect you to need about three times the
design size.

This code seems to introduce combinatorial paths with length of more
than 10k gates.
Don't do this. I guess even 100 gates per path will kill your tool.

BTW: you do this for fault testing, right? Doubling your design to
achieve a fault coverage seems the wrong way for me

bye Thomas




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