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
2017JanFebMarApr2017

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 41325

Article: 41325
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: "Arbitrary" <wackedy@XXXhotmail.com>
Date: Tue, 26 Mar 2002 03:33:25 GMT
Links: << >>  << T >>  << A >>
 > These devices seem kind of sensitive. I recently built myself a
> ByteBlasterMV cable and a small pcb for an EPM7064S with headers for all
> pins and JTAG. The first time I tried it everything seemed to work ok, I
> could examine the chip and readout the data(though I thought the chips
would
> be blank when purchased but it was not). Then I wired everything up to
test
> the program I wrote and it didnt work anymore.
>
> Arbitrary

 As it turned out the chip was not fried. The error was caused by a bad
solder joint on the test PCB. The bad solder joint was on the TDO pin which
explains the behaviour i saw before. But I guess I should thank you all
since this thread got me to look for possible errors one more time.
Damn me for making the pads so small :)

Arbitrary



Article: 41326
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: brimdavis@aol.com (Brian Davis)
Date: 25 Mar 2002 20:37:09 -0800
Links: << >>  << T >>  << A >>
Tim wrote:
>>> Brian Davis wrote:
>>>  in the synthesis of nearly identical circuit constructs:
>>>
>>>    ts_mux <= a_in  when sel = "00" else  'Z';
>>>    ts_mux <= b_in  when sel = "01" else  'Z';
>>>    ts_mux <= c_in  when sel = "10" else  'Z';
>>>
>>>    process
>>>      wait until rising_edge(clk);
>>>       sig1 <= ts_mux;
>>>       sig2 <= ts_mux AND '1';
>>>    end process;
>>>
>>>    In functional simulation, sig1 will propagate a 'Z', whereas
>>>  sig2 will propagate an 'X', due to the AND operator resolving
>>>  the 'Z' to an 'X'.
>>>
>>>    So, following Ken's "match the simulation quirks at any price"
>>>  synthesis policy, this means that sig1 should have a tristate
>>>  after the FF, but sig2 should not!
<snip>
>>
>Isn't Brian's example something which, though OK for sim,
>should be flagged for synthesis?  If this is what is meant,
>would it not be a good idea for the code to say so:
>
>   ts_mux <= a_in  when sel = "00" else  'Z';
>   ts_mux <= b_in  when sel = "01" else  'Z';
>   ts_mux <= c_in  when sel = "10" else  'Z';
>   ts_mux <= 'H'; -- synth looks at its technology data base
>                  -- to see if this results in a well-controlled
>                  -- signal into the flop.  otherwise, warns/errors.
>  process
>    wait until rising_edge(clk);
>     sig1 <= to_x01(ts_mux);
>     sig1_enable <= sel="00" or sel="01" sel="10";
>  end process;
>
>  final_output <= sig1 when sig1_enable else 'Z';
>

   That's a pretty good description of what Synplify actually
 builds at the output pin given the original code.

   Just to make myself clear, I don't think that's what SHOULD be
 synthesized from the original code; I was just creating a simple
 example to show the strange differences in generated logic that
 would result from a working implementation of this tristate 
 pushthrough feature.

>
>And "sig2 <= ts_mux AND '1';" just gets a warning from the synth
>- "not a supported metaphor
>
   Since the overloaded std_logic_1164 operators know how to resolve
 signals from 'Z' to 'X', the "sig2 <= ts_mux AND '1'" should resolve
 the ts_mux signal just as does the "to_x01(ts_mux)" of your example.

   You bring up another very good point, though: hanging an 'H' driver
 off the tristate bus would also prevent the input to the flip-flop
 from ever taking on a 'Z' state.

   I'll try that out when I get a chance; any wagers on what Synplify
 does with that one?  I'll go with "still builds a tristate output".

thanks,
Brian

Article: 41327
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: brimdavis@aol.com (Brian Davis)
Date: 25 Mar 2002 20:43:34 -0800
Links: << >>  << T >>  << A >>
Before rambling on again, let me distinguish between several 
 different issues here:

   Q1:  Does Synplify 7.0.3 let FPGA designers use internal
      tristates to build efficient wide mux structures?

   Q2:  Should a tristate pushthrough "feature" be included
      in synthesizers?

   Q3:  If so, does Synplify implement pushthrough correctly?

 My short answers are:

   A1:  no ( 7.03 / Spartan2 )

   A2:  NO!!!!!

   A3:  no


snippets of what Ken wrote :
>
>>   Real DFFs don't propagate 'Z's from input to output, but a 
>>  functional simulation of the standard synthesis template for
>>  a DFF will propagate 'Z's under certain conditions.
<snip>
>Any difference between RTL and gate level simulation results
>in users sending us very complicated designs and asking us
>to debug them.  
>
   Understood.

   Just like the "add extra logic around the block RAMs" feature,
 you feel you should add extra hardware to "fix" what is really a 
 simulation/modeling problem.

   I respectfully disagree with this policy.

   Any such synthesis "features" should be disabled by default,
 and if enabled, generate warning messages when they kick in.

>>
>>   I firmly believe that this tristate pushthrough behavior
>>  is incorrect, as it will lead to serious inconsistencies
>>  in the synthesis of nearly identical circuit constructs:
>>
<snip>
>
>Your argument is not really that it is "incorrect" to produce
>a functional match between the RTL and gate level simultion, but
>rather that it is impractical.
> 
   Perhaps "pathological" would have been a better choice of words,
 as in "I firmly believe that this tristate pushthrough behavior
 is pathological"

   There have always been, and will always be, simulation/synthesis/HW
 mismatches; I certainly don't expect Synplify to synthesize a
 register that actually propagates 'X's in the real world ( please
 tell me that's NOT a feature coming soon in 8.0 ).

   Normally, tristates are generated only under specific, well defined
 RTL coding guidelines; with this new "feature", minor code changes in 
 one part of the chip can cause tristates to magically appear and disappear
 on output pins many pipeline stages away. 

   The only time a tristate should be created AFTER a register is
 if the designer explicitly codes one there, either with a separate
 tristate signal assignent or by assigning 'Z' in one branch of the
 control statement that generated the register.

>
>  In Aki's test case it looks like we did the transform 
> inefficiently.  We will fix this.
>
  I think this problem (#1) might be a separate issue from the 
 pushthrough feature ( although it may have been broken by the
 new tristate enable analysis code ). If you compile the test 
 code I posted Friday, even with the syn_keep in place to resolve
 the 'Z', the generated hardware shown in  HDL analyst (RTL view)
 is a logical mux followed by a tristate, instead of a mux
 implemented with tristate drivers, even with the tristate-to-mux
 conversion threshold set to 1.

>
>It should in practice turn out to cost very little to maintain
>a behavior match in 'Z' propagation.
>
 Costs of this "feature":

   - toss existing RTL tristate coding guidelines out the window

   - can create complex/wide/deep/slow logic for the merged enable

   - broke the (formerly working) efficient tristate mux generation

   - Synplicity engineering effort to write, debug, and support this
     complex 'Z' propagation analysis code

   - I suspect the final (i.e. working) implementation of this feature
     may have to disable some logic optimizations to function properly

  Benefits of this feature:

    - for some special cases, there is a minor improvement in pre/post
      synthesis simulation matches. ( e.g. a simple RTL register whose
      input is driven to 'Z' in simulation will now propagate a 'Z'
      instead of an 'X' in post synth simulation. )

>
>In any case we did add a switch in 7.1 to select the old behavior.
>
  When will 7.1 be available for download? 

  I'd also love to read a description of this feature in the
 documentation; how on earth are you going to describe the new
 RTL coding guidelines for register and tristate inference? 

 e.g., hypothetical manual entry:

  " Tristate Pushthrough in 7.0.3

      If an internal tristate bus is connected to an inferred
     register, Synplify might sometimes push the tristate though
     said register.

      If the register is inferred by a simple assignent, Synplify
     will push the tristate across the register and any succeeding
     registers, until it is resolved or hits an output port; except
     in those cases when Synplify's enable optimization decides the
     bus is always driven, in which case the tristate will be
     completely eliminated from the design.

      Registers inferred from an assignment involving a logical or
     other operator that resolves the 'Z' will not be subject to
     this pushthrough feature, unless Synplify optimizes the logic
     performing the resolution out of existence, in which case the
     pushthrough might still occur.
  "


>
>Thanks for the very clear feedback.
>

 Thanks for listening.

Brian

Article: 41328
Subject: I2C Slave sampling edge
From: jaime.aranguren@ieee.org (Jaime Andres Aranguren Cardona)
Date: 25 Mar 2002 21:27:10 -0800
Links: << >>  << T >>  << A >>
Hi,

On Xilinx' App Note XAP333 is an design of a I2C Master/Slave
peripheral for a uProcessor, which I've used as basis for designing a
slave device. They say on pag 12 that everything (the state machine
and associated counters and shift registers are clocked on the falling
edge of SCL, 'cause on heavy loaded systems the rise time of the SCL
line may be very slow and that is dangerous on a clock a signal,
'cause it can generate noise on it.

However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they
say the data on the SDA line must be stable during the HIGH period of
the clock.

What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a
XCS05XL?
Sampling on the falling edge (like Xilinx AppNote does) or sampling on
he rising edge (as Philips specification suggests)?

Thanks a lot.

PS/ I would appreciate your replies also be sent to
jaime.aranguren@ieee.org

Article: 41329
Subject: Re: Using GCLK1 as Input on Spartan II under Foundation 4.1
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 26 Mar 2002 01:15:39 -0600
Links: << >>  << T >>  << A >>
Try this Answers Database.

http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10333


Just for my curiosity, does it make any difference if you replace

NET "p_wr_l" LOC =  "P77";

with,

NET "p_wr_l" LOC = "GCLKPAD1";


in your UCF file? (I sort of doubt it because the problem seems
something to do with IBUF and IBUFG.)



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41330
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: sunny <sunshine@sunrise.at>
Date: Mon, 25 Mar 2002 23:49:19 -0800
Links: << >>  << T >>  << A >>
Hi,

1. You should clariy if your MAX+plus 2 settings are ok. 
- MAXPLUS2, PROGRAMMER, OPTIONS, HARDWARE SETUP, BYTEBLASTERMV
- MAXPLUS2, PROGRAMMER, JTAG, MULTI DEVICE JTAG CHAIN SETUP, DEVICE NAME: EPM7128SLC84, PRGRAMMING FILE: <your_proejct>.pof
THe Detect JTAG Chain setup will show you if the device is recognized at all.

2. Do some measurements on TDI, TMS, TCK, TDO according to the appropriate Altera app note.

3. Send an Email to support at altera.com.

4. Try to get a PL-UP-1 university package. Thgis will include an Altera ByteblasterMV, a prinzted circuit board with EPF10K20RC240 and EPM7128SLC84-7 and some other stuff. This one is being sold at 150 bucks, so its quite cheap compared to the 70 bucks you have spend on that download cable which cou could have build for 2 bucks yourself (schematic is available in the ByteBlasterMV datasheet). You can remove the 7128SLC84 with your own part and use the board for programming. Or use the board itself. It has a lot of connectors. For further information you should go to the Altera web page, university program. 

regards 

sunny

Article: 41331
Subject: How to activate 5V PCI I/O pads in FLEX10KE/ACEX1K?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 26 Mar 2002 02:07:21 -0600
Links: << >>  << T >>  << A >>
        I am wondering how I can activate 5V PCI I/O pads in Altera
FLEX10KE/ACEX1K.
I searched FLEX10KE/ACEX1K datasheet, QII 2.0 Web Edition help, and
FLEX10KE PCI development board manual, but none of them seem to mention
how to configure the I/O pads to support 5V PCI.
Yes, 3.3V PCI I/O is easy since since all I have to do is to select 3.3V
PCI for the I/O pads (I can select that from QII.), and also turn on PCI
Clamping Diode.
For 5V PCI, should I use 3.3V LVTTL I/O pads, and turn off PCI Clamping
Diode, or are there other ways to do it?
        Some people who have read my past postings regarding Altera
design tools probably remember me as an Altera nay-sayer, and, yes, I am
still an Altera nay-sayer, and I don't really like QII WE,
LeonardoSpectrum-Altera, or FLEX10KE/ACEX1K compared to Xilinx's similar
offerings (ISE WebPACK, XST, and Spartan-II).
But I do still play around with Altera tools/devices when I feel like,
and I guess right now I am feeling like playing around with Altera's
stuff.
If you didn't like what I said in the past (I still believe they were
fair comments from a Xilinx ISE WebPACK 4.1 user's point of view.), I am
not really going to beg for your advise since I don't actually own a PCI
card with an Altera FPGA (Okay, a LUT-based PLD . . .) on it, so it is
not really important to get my PCI IP core to work on on Altera FPGAs.
(The PCI IP core is doing fine on Insight Electronics Spartan-II PCI
card without any vendor specific optimizations.)
I just thought it will be nice if I can get my design to do well on
FLEX10KE/ACEX1K since that's the last Altera FPGA that supports 5V PCI
(in -1 speed grade).



Thanks,



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41332
Subject: Re: I2C Slave sampling edge
From: mwnews@pentax.boerde.de (Matthias Weingart)
Date: 26 Mar 2002 09:34:56 +0100
Links: << >>  << T >>  << A >>
[posted and mailed]

jaime.aranguren@ieee.org (Jaime Andres Aranguren Cardona) wrote in 
<14a86f87.0203252127.93e1de@posting.google.com>:

>Sampling on the falling edge (like Xilinx AppNote does) or sampling on
>he rising edge (as Philips specification suggests)?

Sampling on the falling edge should be sufficient and Xilinx
already suggest it, why not? I agree with them that the falling edge is 
much sharper. But remember with SCL low SDA can be changed, but 
it needs some time to see new data there
e.g. PCF8574: 
t(vd;dat)=SCL LOW to data out valid=3.4us max
but 
t(hd;dat)=data hold time=0 ns,
after SCL is going low the data are immediately invalid!
(SCL low is defined as <0.3V Vdd, however I would sample SCL at Vdd/2)

In the AppNote I read that the bus is working at up to 100kHz,
but this is no longer true 400kHz are state of the art, and I
have seen devices that operates at 1MHz. Be sure that your
slave device can work with at least 400kHz.

M.


Article: 41333
Subject: Re: High speed clock routing
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 26 Mar 2002 08:37:27 +0000
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:


> > IIRC you are doing a C6711 design?  I did a C6711, two flash, two
> > SDRAM (ith two footprints each to accomodate 64MBit and 256MBit
> > devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-).  It ended up as
> > a daisy chain, with series terminators on the FPGA datalines as its
> > edges were horrible.  The C6711 has (according to TI) been designed
> > with slower edges than the previos C6x family so it doens;t need
> > terminators as it is a low cost device - and that did seem to be the
> > case.
> 
> I am a little confused by what you said.  You say that the edge rates on
> the C6711 seem to be slower than other C6x chips, and yet you say that
> you needed terminators since the edges were horrible.  I don't
> understand.  Did you mean that the C6711B was redesigned?  
> 

Sorry, I was unclear!  The FPGA edges were horrible so the data lines
needed terminating.  The address lines (driven only by the DSP) were
fine, in fact slower than I would've liked, but they were driving a
large number of devices.  I don't know about the C6711B, have you
beaten an IBIS model out of them yet?  The first one I got from TI for
the C6711 was great - no driver information at all!

Good luck!

Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 41334
Subject: Re: Xilinx 4.2i not working on my design
From: "David Frith" <david.frith@ffei.co.uk>
Date: Tue, 26 Mar 2002 09:01:48 -0000
Links: << >>  << T >>  << A >>

"emanuel stiebler" <emu@ecubics.com> wrote in message
news:3C9F8E16.8DD470F5@ecubics.com...
> David Frith wrote:
> >
> > Hello all
> >
> > I've just loaded on ISE 4.2i and the first design I ran through gives me
an
> > error at ngdbuild. This is with exactly the same input files as 4.1i
which
>
> Did you instal the SP1 already ? Probably it goes away ...

Installed SP1. No difference.

David



Article: 41335
Subject: VCC and GND net warnings with ispDesignExpert
From: "David Brown" <david_no_spam@no.spam.westcontrol.com>
Date: Tue, 26 Mar 2002 10:09:08 +0100
Links: << >>  << T >>  << A >>
Hi,

I am using ispDesignExpert for a Lattice Mach4 design in VHDL.  One extremly
annoying thing is that for almost all vhdl modules, I get a compiler
warning:
    EDIF2BLIF: Warning: Net VCC is floating and will be removed
and similarly for GND.  The warnings do not appear if the code actually
makes use of std_logic '0' or '1', since these obviously get connected to
the VCC or GND nets.  The warnings do not do any real harm, but being a
newbie to VHDL I get more than enough warnings and errors as it is - I would
much prefer to get a nice green tick when the code compiles, rather than
these irrelevant warning messages.  Does anyone know any tricks to avoid
them, or is it possible to disable them?

Thanks.

--
David Brown
WestControl a.s
Norway



Article: 41336
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: "Dan Oprisan" <dandy1313@yahoo.com>
Date: Tue, 26 Mar 2002 10:12:39 +0100
Links: << >>  << T >>  << A >>

"James Thurley" <newsgroups@NO.SPAM.PLEASE.jamesthurley.com> schrieb:
> I'm using a NEF-A-P (http://www.nefdesign.com/) programmer because it's
> cheaper than the ByteBlasterMV and works at a good range of voltages.  I'm
> assuming this is in good working order...
>
> I'm pretty sure I've got everything connected correctly - I've checked
many
> times (following the altera diagrams and the report file for my program) -
> but when I click on "Detect JTAG Chain Info" in the Altera Stand Alone
> Programmer it says it can't detect any devices.
>

Look at the original Altera Byte-Blaster Design. It has 2 Loopbacks, so that
the software is able to detect the kind of adapter used. I dindn't saw them
in the NEF-A-P design.

Is the software installed corectly? (LPT drivers etc.)

I think it is possible for the JTAG pins to be disabled. Once this is the
case, you only can enable them with a standard programer. Check another
CPLD.

Dan




Article: 41337
Subject: FLEX10KE/ACEX1K IOE Packing Rules
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 26 Mar 2002 03:23:49 -0600
Links: << >>  << T >>  << A >>
        Okay, here is my second Altera FLEX10KE/ACEX1K related question.
Again, if you don't like me because of my past comments about Altera, I
am not going to beg for your advise.
        To get an output FF merged into an IOE, I will have to add the
following line in a .esf file.

'pin name' : FAST_OUTPUT_REGISTER = ON;


However, here are some of the problems I got when I synthesized my PCI
IP core.

* Can't pack non-peripheral register <name> to bidir I/O pin <name> --
output register and TRI or OPNDRN primitives cannot both fan-out

* Can't pack non-peripheral register <name> to I/O pin <name> --
register requires a preset in an I/O cell


Looking at the FLEX10KE and ACEX1K datasheet, unlike a Xillinx
Spartan-II IOB, a FLEX10KE/ACEX1K IOE seems to have a feedback path
going back to the LAB, thus it seem like the synthesis tool won't have
to automatically duplicate the FF to get it inside an IOE.
Then, why will get the above problems?
Several months ago when I was dealing with Spartan-II IOB packing rules,
it took me a lot of time and effort to figure it out, and even recently
I had some problems with it (See "XST duplicates unnecessary IOB OE FFs"
if you are interested.), so I am not terribly surprised that I am in the
same situation again.
        Thinking about the second error, it seems to me that
FLEX10KE/ACEX1K IOE FF having only an asynchronous Clear, and not an
asynchronous Preset seems to be the reason why I got the error.
QII 2.0 WE's help said there is a synthesis option called "NOT gate
push-back" that supposedly solves this issue, but sounds like a risky
synthesis option.
What are the consequences (side effects) of using this NOT gate
push-back?
In PCI, most control signals like FRAME# or IRDY# are active low, and
their state after reset is logical high (1), so an IOE output FF not
having an asynchronous Preset seems like a major problem.
At least in Spartan-II, I never encountered this problem.



Thanks,



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41338
Subject: Re: Pipelined sorting algorithms...
From: Christopher.Saunter@durham.ac.uk (Christopher Saunter)
Date: Tue, 26 Mar 2002 10:25:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
A couple of other thaughts:

1)  It's pretty inefficient to carry all 32 bits of each word through the
sorting logic.  How about haveing 16 32bit fifos of equal length to the
sorting pipeline, clock the 16 words into them each cycle.  Extract the 4
bit key from the word and attatch a 4 bit pointer to the fifo containing
the 'parent' word, and just sort this.  You would then use the pointers
emerging from the sort to reorder the data emerging from the fifos.  This
would need a lot of logic in itself (or a lot of tristates) but would
probably save some.  Also, cutting the size of the sort algorthim by a
factor of 4 might make it easier to speed up.

2)  It's not the case that the 4 bit keys are all unique is it?  Probably
a daft question.

Cheers,
	Chris Saunter

Article: 41339
Subject: clock source
From: "Sławomir Balon" <antyspam.bsl@post.pl>
Date: Tue, 26 Mar 2002 13:04:45 +0100
Links: << >>  << T >>  << A >>
Hi!
I'm looking for fast clock source (200MHz) for epm7032b, it will produce
four phase shifted by 90 degree 50MHz clocks. What oscilator should i use?
Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that
high freq's. I'm open for any ideas...
BTW how they make lets say: 1GSPS in oscilloscopes (i know that on
repetitions but how they get those phase shifts for ADCs? - ECL??)

thanx
Slawek



Article: 41340
Subject: Re: XST duplicates unnecessary IOB OE FFs
From: hamish@cloud.net.au
Date: 26 Mar 2002 12:31:28 GMT
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
> I personally can live with such an inconvenience, but I cannot live with
> inconvenience of the synthesis tool going against my will, and
> duplicating an OE FF 32 times.
> I think XST has to "trust" the user a little more, and not guess what
> the user is trying to do.

Your code says that you want a flip-flop which is used as an output enable
for your pins. XST has given you a registered output enable for your pins.
The output from the synthesis tool is logically correct and matches
simulation behaviour. You are doing something unusual and in this case
you must specifically ask for it ie by using synthesis primitives.

I think you would be very disappointed with the synthesis results if
the tool didn't do little things like this. For example, state machine
encoding; the tools usually default to one-hot or auto-detect but
the most obvious code probably implies a binary encoding. Similarly,
no register duplication or buffering which would give significantly
worse timing results in some designs. You also depend on the tool
for automatic IBUF/OBUF/IOBUF instantiation which saves a lot of
time and a lot of messy code.

There is no way that the tool can please everyone. It can either
be dumb by default (which will suit you in this case but not
many other people) or smart. There will always be times when
you have to disable the smart behaviour. As long as that is
easy, the smart behaviour is the correct default.

My only complaint would be that it's often too difficult to
disable these optimisations.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 41341
Subject: how to prevent infer of Mult18x18 in VirtexII
From: ospyng@yahoo.com (spyng)
Date: 26 Mar 2002 05:38:48 -0800
Links: << >>  << T >>  << A >>
hi all,
anyone know how do can I prevent the infer of mult18x18 in Virtex II?
I have a resources conflict with Block Ram and I only need to complete
the mult in 4 cycle @ 100 mhz.

any switch during map or UCF constraint I can use?

I am using Synplify pro and ISE4.2

thanks
pyng

Article: 41342
Subject: Re: Using GCLK1 as Input on Spartan II under Foundation 4.1
From: "Robert S. Grimes" <rsg@payload.nospam.com>
Date: Tue, 26 Mar 2002 14:30:43 GMT
Links: << >>  << T >>  << A >>
Thanks Kevin,

Excuse me while I wipe the egg off my face...  Hey, I had looked at that
page in the Answers Database, but I wasn't sure how to follow the solution
(obviously, I'm new to VHDL!), and I wasn't sure if it related to my problem
or not, so I posted just before leaving work.  So, when I got your post, I
decided to try it (guessing if necessary!), and lo and behold, it worked
like a charm, first time!  So, lesson learned: don't be so damn timid!

Thanks again!

"Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in
message news:a7p6m9$qj7$2@newsreader.mailgate.org...
> Try this Answers Database.
>
>
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
1&getPagePath=10333
>
>
> Just for my curiosity, does it make any difference if you replace
>
> NET "p_wr_l" LOC =  "P77";
>
> with,
>
> NET "p_wr_l" LOC = "GCLKPAD1";
>
>
> in your UCF file? (I sort of doubt it because the problem seems
> something to do with IBUF and IBUFG.)
>
>
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)



Article: 41343
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: "James Thurley" <newsgroups@NO.SPAM.PLEASE.jamesthurley.com>
Date: Tue, 26 Mar 2002 14:38:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Thanks very much for everyones help - I took everything over to uni and had
a look at the JTAG outputs, but the strange thing was they all seemed to
just be sitting at 5v.  I think I may have done something wrong in testing
because I wired up an led between TMS and ground and the led wasn't very
bright relative to the others, but acording to the osciloscope it was also
at a steady 5v which seems to be a contradiction.  I'm didn't have enough
time to look into this thoroughly though because the labs are shutting down
for the holidays - I'll have to wait till next term to try it out again.

I did manage to program the chip using their out of system programmer
though, so I know the chip is ok and I know at worst I can use that.

Thanks again for all the advice,
James.



Article: 41344
Subject: Re: how to prevent infer of Mult18x18 in VirtexII
From: sunny <sunshine@sunrise.at>
Date: Tue, 26 Mar 2002 06:41:36 -0800
Links: << >>  << T >>  << A >>
u could use the synplify attribute
syn_multstyle = logic. This would prevent Synplify of using the 18x18 multiplier. Information will be forward annotated to ISE thru the ncf.

Article: 41345
Subject: failure rate of Xilinx chips
From: vlad@comsys.ntu-kpi.kiev.ua
Date: Tue, 26 Mar 2002 16:43:18 +0200
Links: << >>  << T >>  << A >>
Hi All ,
Where can I find information about numerical characteristic of failure
rate of Xilinx Óhips(Spartan2, Virtex series)? This information is
needed for calculation  reliability index of entire device.

-- 
Best regards,
 Vladislav Vasilenko      
Hardware engineer. National Technical University of Ukraine

mailto:vlad@comsys.ntu-kpi.kiev.ua

Article: 41346
Subject: clock multiplier
From: "Sławomir Balon" <antyspam.bsl@post.pl>
Date: Tue, 26 Mar 2002 15:56:28 +0100
Links: << >>  << T >>  << A >>
Hi!
Is there any idea for multiplying clock in max7000 devices?
thanx
Slawek



Article: 41347
Subject: Re: Xilinx 4.2i not working on my design
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Tue, 26 Mar 2002 17:19:16 +0200
Links: << >>  << T >>  << A >>
Can't really tell you how to fix your problem, other than the advice that
you should always finish a design/project to completion using the same
software before upgrading. I'm still using Foundation 3.3 with ISE 4.1 & 4.2
still in their boxes, and I'm not taking them out till I have finished my
project.

adrian


> > David Frith wrote:
> > >
> > > Hello all
> > >
> > > I've just loaded on ISE 4.2i and the first design I ran through gives
me
> an
> > > error at ngdbuild. This is with exactly the same input files as 4.1i
> which
> >
> > Did you instal the SP1 already ? Probably it goes away ...
>
> Installed SP1. No difference.
>
> David
>
>



Article: 41348
(removed)


Article: 41349
Subject: Re: I2C Slave sampling edge
From: yuryws@optonline.com (Yury)
Date: 26 Mar 2002 08:25:29 -0800
Links: << >>  << T >>  << A >>
I looked at various implementations of I2C interface and from what I
saw it is indeed better to use the falling edge, since the rising edge
is due to a tri-state pulled-up and the falling edge is due to a
signal actively driven low. I chose the falling edge in my design. My
fast (45MHz) clock is used for edge detection. It is recommended to
have an anti-glitch filter on SCL/SDA lines - rising/falling times
could be long. 100 KHz+_ no probems. 400KHz did not try yet.



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
2017JanFebMarApr2017

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