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 112325

Article: 112325
Subject: Re: board - T562.jpg
From: "Joel Kolstad" <JKolstad71HatesSpam@yahoo.com>
Date: Mon, 20 Nov 2006 09:57:48 -0800
Links: << >>  << T >>  << A >>
"Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote in message 
news:12m3qjn4fcl0jec@corp.supernews.com...
> I hope that the "students are not to be trusted with untyped languages" idea 
> is universal

That should be "ISN'T" universal.



Article: 112326
Subject: Re: Spartan3E price update ?
From: "rickman" <gnuarm@gmail.com>
Date: 20 Nov 2006 10:48:21 -0800
Links: << >>  << T >>  << A >>
Antti wrote:
> tullio schrieb:
>
> > It's about a year that Spartan3E are on the market but i am still
> > confused on pricing.
> > On: http://www.xilinx.com/products/spartan3e/faq105-sp3e.pdf  xilinx
> > states that
> > XC3S1200E is less than $9.
> >
> > On the major distributors (Nu Horizons, Avnet) the same part goes for
> > about $45.
> > Is $9 a marketing thing only, or is there any chance that quantity
> > prices will drop to that level ?
> >
> > tullio
>
> did you ask quote for 500,000 pieces single order? its clearly stated
> this is possible price for 0.5M pieces orders only.
>
> for smaller orders you may be able to get the price down to around $20
> USD slowest speed cheapest package, but dont expect prices below that
> unless you are really buyins millions of pieces.

I seriously doubt the 1200 will see $20 even in the smallest package
unless you are looking at a huge number.  I had a quote on the 3S400 in
the FG456 at qty 50k and it was still only $20.  the 1200 is three
times larger and even in the FG256 package it is going to cost a bit.

Like Antti said, the published numbers are for literally million piece
orders, and even then only if you beat them about the head and
shoulders.  That is why it is economically to your advantage to design
your product so you can use more than one brand of FPGAs.  Then you can
leverage a competitive bid and literally get half the price you might
get otherwise.  The vendors (at least the Xilinx vendors) will try to
tell you the best way to save $$$ on the chips is to tailor your code
to their brand of chip cutting the LUT count and going with a smaller
part.  But that might get you a savings or it might not.  But having
the option of buying the parts from another vendor will definitely get
you a better price on *any* part you decide to use.

Although they can be stupid about that too.  I once was designing a
Lucent part into my board.  A vendor wanted to compete the Xilinx part
on price and I gave them the parameters I used to select the part.
When they came back with a price and I told them that was much higher
than the Lucent part they asked me which one.  I gave them the part
number and they tried to tell me their competitive part was different
from the one they had picked from my specs.  Yes, the new part was
cheaper than the Lucent part (a little), but it didn't have enough I/Os
for my design and would not work!  I tried to explain it to them and
they refused to believe that their part was not equivalent.  Talk about
stupid!!!


Article: 112327
Subject: Re: Spartan3E price update ?
From: "rickman" <gnuarm@gmail.com>
Date: 20 Nov 2006 10:51:15 -0800
Links: << >>  << T >>  << A >>
I forgot to mention that much like buying a car, you should *never*,
*ever* pay list price for FPGAs in any real quantity.  Even if it is
only 1000 a year, you can likely get 20% to 50% off of distributor list
just by asking for it.  You can get closer to 50% if you tell them a
target price and that you are shopping it around to the different FPGA
makers.


Article: 112328
Subject: DDR_VDHL_models
From: Vangelis <>
Date: Mon, 20 Nov 2006 11:05:58 -0800
Links: << >>  << T >>  << A >>
Does anynone know where can I find VHDL models for DDR modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR model will do the job.

Article: 112329
Subject: Re: board - T562.jpg
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Mon, 20 Nov 2006 11:19:19 -0800
Links: << >>  << T >>  << A >>
On Mon, 20 Nov 2006 09:48:37 -0800, "Joel Kolstad"
<JKolstad71HatesSpam@yahoo.com> wrote:

><pbdelete@spamnuke.ludd.luthdelete.se.invalid> wrote in message 
>news:4560c4d3$0$486$cc7c7865@news.luth.se...
>> I heard an interesting comment once, students are not to be trusted with
>> untyped languages because they can't handle it. STILL same persons are
>> expected to handle advanced math with pen & paper..
>
>...and the computer-algebra system running on their calculators!
>
>I hope that the "students are not to be trusted with untyped languages" idea 
>is universal; I'd be shocked if there weren't universities where, e.g., Python 
>isn't being used on a regular basis.  (If John Larkin wasn't already quite so 
>fond of PowerBasic I'd suggest he'd probably really like Python...)
>
>

I like the PB Dos version because it can directly access hardware. I
can do INs and OUTs, and dimension an integer array *at* an address
that just happens to be a VME crate or a PCI device. Under DOS or '98,
of course. Or drop into assembly anywhere I feel like:



	' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
	' \\\\\\\\\\\\\\\\\\\\ IN16 \\\\\\\\\\\\\\\\\\\\\
	' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

SUB IN16(PORT, DTA)

	' READ A 16-BIT PORT
        '  PORT  IS PORT ADDRESS
        '  DTA   IS RETURNED DATA

        LOCAL P, D		' WE MAKE LOCAL COPIES OF PARAMETERS
				' TO MAKE ASM LINKAGES EASY.

	P = PORT		' RECOVER CALLER'S PORT ADDRESS

	ASM	MOV DX, P       ; GET PORT ADDRESS IN DX
	ASM	IN  AX, DX	; READ PORT DATA INTO AX
	ASM	MOV D, AX	; POKE DATA INTO BASIC VARIABLE

	DTA = D			' AND RETURN HIS DATA

END SUB







	' SEARCH THE PCI BUS FOR THE TUNDRA CHIP

ASM	MOV	AH, &HB1     	; THIS BLOCK OF ASM CODE LOCATES THE
ASM	MOV	AL, &H02        ; TUNDRA UNIVERSE CHIP VIA THE VENDOR
ASM	MOV	CX, &H00        ; AND DEVICE ID. THEN IT RETURNS THE
ASM	MOV	DX, &H10E3      ; BUS NUMBER AND THE FUNCTION NUMBER
ASM	MOV	SI, &H00        ;
ASM	INT	&H1A            ;
ASM	MOV	RECODE?, AH     ;    RETURNED STS, 0 = SUCCESS
ASM	MOV	BNUM?, BH	;    PCI BUS NUMBER
ASM 	MOV	FUNN?, BL	;    DEV/FUNCTION NUMBER

	IF RECODE? THEN		' DO WE HAVE A CHIP?
           E$ = "TUNDRA CHIP NOT FOUND"
           GOTO FATAL
        END IF


	' NOW USE A CONFIG SPACE WRITE TO RELOCATE THE TUNDRA

ASM	MOV	AH, &HB1        ; SUBFUN CODE = B102, WRITE CONFIG LW
ASM	MOV	AL, &H0D        ;
ASM	MOV	BH, BNUM?       ;    BUS # FROM ABOVE
ASM 	MOV	BL, FUNN?       ;    AND DEV/FUN FOR TUNDRA
ASM	MOV	DI, &H10        ;    OFFSET TO PCI_BSO BASE ADD REG
ASM	DB	&H66            ; USE 32-BIT OPCODE PREAMBLE
ASM	MOV	CX, TUNLOC	; TO LOAD ECX WITH 32-BIT ADDRESS
ASM	INT     &H1A		;    THEN RELOCATE TUNDRA THERE!




John


Article: 112330
Subject: Re: false path
From: "Hans" <hans64@ht-lab.com>
Date: Mon, 20 Nov 2006 19:27:03 GMT
Links: << >>  << T >>  << A >>
"gen_vlsi" <jesuraj.vinoth@gmail.com> wrote in message 
news:1164004615.735540.80450@h48g2000cwc.googlegroups.com...
> Hi .
>
>    Can anyone throw some light on false path and how to determine it
> during synthesis.
>

See:

http://www.ht-lab.com/misc/false_path.html

This is quite a simple example but you can see that the data can only "flow" 
from xy1_s to xa2_s and from xa1_s to xy2_s. This means that the path 
through both multipliers is false.  If the tpd of the multiplier is 100ns 
and the adder 10ns then your P&R tool might give you a total tpd of 200ns 
rather than 110ns.

Finding these path is normally very time consuming and the way to tackle it 
is to only focus on the most negative slag path and work your way through 
the schematic and RTL. There are also tools that find these path 
automatically (e.g. Focus from Fishtail) but they are more for ASIC's than 
for FPGA's although I know that Focus also supports FPGA's,

You might also want to google for Static and Dynamic sensitised paths,

Hans
www.ht-lab.com 



Article: 112331
Subject: DDR_SDRAM_VHDL_models
From: Vangelis <>
Date: Mon, 20 Nov 2006 11:38:11 -0800
Links: << >>  << T >>  << A >>
Does anynone know where can I find VHDL models for DDR-I SDRAM modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR-I SDRAM model will do the job.

Article: 112332
Subject: Spartan 3 Starter Kit .mcs upload problem
From: =?ISO-8859-1?Q?J=FCrgen_B=F6hm?= <jboehm@gmx.net>
Date: Mon, 20 Nov 2006 20:58:41 +0100
Links: << >>  << T >>  << A >>

Hi,

I have a problem in uploading an .mcs file from the Spartan 3 Starter
Kit reference designs to the flash prom.

Specifically it is the design "Micro Blaze Master System" from

www.xilinx.com/products/boards/DO-SPAR3-DK/reference_designs.htm

I use Impact from the ISE WebPack vers. 8.1 and follow the standard
prescription for uploading .mcs files which - for example - always works
with the factory default .mcs or the .mcs I produced from own designs.
Concretely I assign the chosen .mcs file to the flash prom with Impact,
select the prom type xcf02s and then execute "program" with "verify"
selected.

But in the case mentioned above ("Master System") this gives me an error
in the verification phase after the upload. The error is accompanied by
a message "non contiguous address" (or the like).

What could be the reason for this ? Hardware fault ? Incompatibility
with newer Impact ? Wrong procedure on my side ?

To check for hardware problems I tried "blank" with "verify empty" on
the prom with Impact, this went through without error.

I would be very happy if someone could help me resolve this problem, so
that I can test all features of the board with this example design.

Greetings

Jrgen

-- 
Jrgen Bhm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?"  R. Thom

Article: 112333
Subject: Re: DDR_VDHL_models
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 20 Nov 2006 15:36:43 -0500
Links: << >>  << T >>  << A >>
> Does anynone know where can I find VHDL models for DDR modules?

Check out www.micron.com

/Mikhail



Article: 112334
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Mon, 20 Nov 2006 21:49:25 GMT
Links: << >>  << T >>  << A >>
John Larkin wrote:
> On Sun, 19 Nov 2006 20:27:06 +0100, "petrus bitbyter"
> <pieterkraltlaatditweg@enditookhccnet.nl> wrote:
> 
>>
>>
>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schreef in 
>> bericht news:1ejvl2d3j9tj96emac307rtjfr2l4o40q1@4ax.com...
>>> On Sun, 19 Nov 2006 00:24:34 GMT, PeteS <peter.smith8380@ntlworld.com>
>>> wrote:
>>>
>>>> John Larkin wrote:
>>>>> On Sat, 18 Nov 2006 23:23:30 GMT, PeteS <peter.smith8380@ntlworld.com>
>>>>> wrote:
>>>>>
>>>>>> When I do pure hardware I do not have to try and figure out what the
>>>>>> hell was done to implement my statements.
>>>>>>
>>>>>> This was a major issue on a design I did about 4 years ago where I
>>>>>> interfaced an upstream bus to the busses on 6 devices (with a lot of
>>>>>> other stuff) and the synthesis / PAR etc kept optimising away certain
>>>>>> things that were there to maintain the timing. The response I got was
>>>>>> 'well, use pure synchronous design' but in this case it was simply not
>>>>>> possible (am issue I am sure you'll understand).
>>>>> Yup, this *is* the real world. We recently had to do a clock-edge
>>>>> deglitcher, using delay elements. It couldn't be synchronous, because
>>>>> we were, well, deglitching the clock! Ditto stuff like charge-pump
>>>>> phase detectors, where you really need exactly what you need, delays
>>>>> and all.
>>>>>
>>>>>
>>>>>> I once deliberately did a DeMorgan transform by hand because I did nto
>>>>>> trust the tool to do it right. (Code available on request ;) )
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> PeteS
>>>>>
>>>>> One thing you can do is add a pulldown to a pin (or ground it) and
>>>>> call that signal ZERO or something. Then just OR it with things to
>>>>> create new, buffered, delayed things. If you need more, run it through
>>>>> a shift register and create ZERO1, ZERO2, etc. The compiler can't
>>>>> optimize them out!
>>>>>
>>>>> So the FPGA software people ought to provide us an irreducible ZERO
>>>>> without wasting a pin, or a buffer that stays a buffer always.
>>>>>
>>>>> So, is there a block of logic so complex that the compiler can't
>>>>> figure out that it indeed will always output a zero? Maybe the MSB of
>>>>> a thousand-year counter, but that wastes flops. Maybe some small but
>>>>> clever state machine that always makes zero but is too tricky to be
>>>>> optimized?
>>>>>
>>>>> John
>>>>>
>>>> As noted, I once did a DeMorgan transform by hand (simple one too) and
>>>> it materially changed the compiled output. (For those who understand the
>>>> transform, don't get upset at the comments; they were there for people
>>>> who _didn't_).
>>>>
>>>> Here it is:
>>>>
>>>> ******************************
>>>>
>>>> else begin
>>>> cs0 <= cs_l; // make a direct copy of the cs signal
>>>> cs1 <= (cs0 | cs_l); // Note - this uses a DeMorgan transform
>>>> // the formula really is this : cs1 <= !(!cs_l & !cs0)
>>>> // rather than cs1 <= (!cs_l & !cs0)
>>>> // Note the extra output inversion, which renders an
>>>> // inversion unnecessary
>>>> // DeMorgan's theorem is this
>>>> // <y = !a & !b> === <!y = a | b>
>>>> // i.e. invert all signals and change and to or and vice
>>>> // versa. Note this works only on basic functions
>>>> // ( &, |, ! ) (AND, OR, INVERT)
>>>> // for a valid select, we need two consecutive samples of
>>>> // cs_l low. Latch a low, then look at the latch and the
>>>> // signal on the pin. If both are low, cs1 goes low. If
>>>> // either are high (glitch, runt pulse) then cs1 stays high
>>>> // We trigger on internal cs (cs1) going low
>>>> // Why did I use it? Because it requires no inverters and
>>>> // therefore saves me a gate delay by simply using a LUT
>>>> // without inversion
>>>> //
>>>> // Of course, the tools *might* do this, but I can't
>>>> // guarantee it, so I'll *****ing so it myself.
>>>> end
>>>> *****************************************
>>>>
>>>> Cheers
>>>>
>>>> PeteS
>>> They should back off this religious devotion to fully synchronous
>>> logic and give us a couple of dozen programmable true delay elements,
>>> scattered about the chip. But they won't because it's not politically
>>> correct, and because they figure that we're so dumb that we'd get into
>>> trouble using them.
>>>
>>>
>>> John
>>>
>> Well, synchronous design is easier and more understandable then 
>> asynchronous. So the "specialists" tell the world synchronous design is the 
>> only way rather then confess they are unable to make reliable asynchronous 
>> ones. And let's be honest. A lot of old asynchronous designs are real 
>> nightmares of critical race conditions, ad hoc inserted RC delays, glitches 
>> and tricks. Good asynchronous engineering is rare and was rare even in the 
>> days synchronous design was not yet invented. (Practised may be the better 
>> word.)
> 
> There are some people doing serious (cpu-scale) async logic, but
> that's pretty thin-air stuff. What I meant was that, even in a
> properly synchronous design, there are times where a real, analog
> delay is a useful design element, and it sometimes can save a full
> clock worth of time... not all data paths need a full clock to settle.
> Plus, it would be nice to be able to dynamically tune data:clock
> relationships and such. I have one architecture that we use a lot that
> simply must have a real, unclocked one-shot (among other things, it
> stops and resets the clock oscillator!) so we have to go off-chip to a
> discrete r-c.
> 
> 
>> I ever was asked to "debug" a time critical circuit. Looking at the 
>> asynchronous circuit which failed only once a week or so and reading the 
>> full page of explanations about the inner workings I discarded the whole 
>> design, doubled the clock frequency and made a rock solid synchronous 
>> circuit. They were almost disappointed it was that "eas". I could have made 
>> disciples for "synchronous only" but I'm not a true believer myself.
>> Times they are a changing. I heard rumours asynchronous design has a revival 
>> as it can be used to build faster circuits. There should be special software 
>> for it, meant to design processors and the like. It's those software that 
>> makes me shiver. When the first micros hit the market, an engineer 
>> complained that those programmers used lots of extra space. He would have 
>> been fired by using only one percent of that number in extra gates. (Nothing 
>> to do with old uncle Billy :) Things did not grow better ever since but the 
>> real bad development is the habit of those programmers to think and make 
>> decisions for me. I really hate that. Almost all of these programmers have a 
>> theoretical background in "software engineering". Ever visited such a 
>> college with lots of computers, tens of masters and hundreds of students and 
>> no one could handle a soldering iron. There was none in the whole place.
> 
> I toured the Cornell EE department recently. 95% of the screens are on
> PC's, maybe 5% are oscilloscopes. No soldering irons in sight, just
> those drecky white plastic breadboards. Tulane, my alma mater, used
> Katrina as an excuse for eliminating the EE department entirely. I
> guess those labs are too expensive, compared to one TA teaching 400
> kids art history in a lecture hall, all at once.
> 
>> An 
>> assistant brought his own one from home when he needs to repair a cable. 
>> None of those "engineers" ever wrote bugfree software, but expect hardware 
>> designs to be it. Nevertheless, if something goes wrong, it's inevitable a 
>> hardware failure. I ever had technicians to exchange hardware seven times 
>> before they stopped to deny it to be a bug in the software. Another time one 
>> of my collegues disassembled a floppy driver to prove it did not met the 
>> drive specifications. (It could not format a floppy and they insisted we 
>> used the wrong brand of floppy although we tried every brand we could lay 
>> our hands on.) They complained about the disassembly rather then admit their 
>> own failure.
>>
> 
> Yeah, there is a lot of ad-hoc async stuff around, full of 555's and
> one-shots and race conditions and such. Disciplined sync design should
> be the starting point from which to cheat.
> 
> 
>> Well, maybe we're doomed. Maybe I'm going to write software. What's worse? 
>> :)
> 
> 
> I'm stuck, all this month at least, rewriting a diastrous, 14,000 line
> mess (68K assembly) that took over a man-year of work to make this
> bad. Programming is OK, but after a couple of weeks of it I get
> depressed... too much like bookkeeping. I can design hardware forever.
> 
> Gotta do the ghastly serial DAC driver next. The Xilinx bit-bang
> serial config thing worked like a charm, even blinking an LED during
> the loop.
> 
> John
> 
> 

Well, I have just done a SPI master/slave block *completely 
synchronously*. If you ever need one, email me (works up to a 4MHz at 
least, which is beyond the spec of the A-Ds I am controlling). Works 
like a charm (I implemented the Motorola style 4 wire interface).

I wasn't completely clear; I prefer synchronous design *where I can* 
There are times I can not. Then there are places it is obviously proper, 
but times it is not.

In an upgraded (being upgraded) design, I have removed a lot of parts in 
favour of an FPGA, and those parts must be duplicated from the 
perspective of the processor. As the interface was previously 
asynchronous, and changing interfaces is a royal pain, I have to 
implement an asynchronous bus. In such cases, I use delay tricks to make 
sure I get the timing I know will work with the measured (and 
documented) timings from the processor.

I could, of course, do synchronous design internally, *provided I run 
the clock fast enough*, but that uses precious power in a handheld unit 
and i can't live with it *simply for a bus interface clock* when it's 
perfectly possible to do it asynchronously. I handle the necessary 
synchronisation to the internal blocks with 2 FF resynchronisers. In 
this case, I would need to run the internal clocks at least at 50MHz 
which would blow my power budget.

That brings up a major advantage of asynchronous design; power consumption.

When my device sleeps, I *stop the clocks completely* except for the 
processor (which stops it's own clocks) and then restart things properly 
later; but the wakeup sequencers must be completely asynchronous.

So is synchronous design better? Depends on the question being asked.

Cheers

PeteS

Article: 112335
Subject: Re: Simple questions on IDELAYCTRL
From: Ray Andraka <ray@andraka.com>
Date: Mon, 20 Nov 2006 17:00:34 -0500
Links: << >>  << T >>  << A >>
lecroy7200@chek.com wrote:

> I can't seem to find a document that calls out the XY locations for the
> IDELAYCTRL.  Where is this information found?
> 
> When I don't use the LOC, the report for P&R says it has used 100% of
> the IDELAYCTRLs.  No surprize.  When I look at the FPGA editor I would
> expext to see all of them listed but instead I only see a small portion
> of them.  Why?
> 
> It appears that if I include an IDELAY that there is some sort of
> requirement on where the IDELAYCTRL is located.   Currently I don't use
> the LOC, let the tool P&R then use the FPGA editor to see where it
> placed it.  Then I use the LOC.   What a pain.  There must be a simpler
> way.   I tell the tools where the IDELAY is to be used, why is it that
> the tools can't place the controller automatically?
> 
> If I select the wrong location for the IDELAYCTRL, the tool does not
> flag an error, the design just fails to work.  You would think it would
> be smart enough to know.
> 


As long as you run all the idelays on the same 200 MHz reference clock, 
and that reference clock runs continuously, you shouldn't need to 
separately reference the idelayctrl's, which means you can just put one 
at the top level of your design and run the idly_rdy to all instances of 
your idelays.  If there is only one idelayctrl instantiated in your 
design, then the PAR tools automatically replicate it and you don't need 
to put any RLOCs on it.  I believe the replication replicates it into 
all sites, and then map later trims out any that are in regions where 
there are no idelays used and the rdy pin is not used. If the rdy pin is 
used, the software instantiates an AND gate to combine all the RDY's 
into one signal, so if RDY is used, all the idelaysctrls remain in the 
circuit.  This will lead to higher power consumption, but otherwise 
doesn't adversely affect the design.  Xilinx does recommend using LOCs 
and explicitly placing these, but like you, I found that highly 
inconvenient.  The only place I think you can get the locations is off 
FPGA editor, and those change depending on the particular device. 
Unless you are either a) concerned about every bit of power consumption, 
b) using the rdy's differently for different banks and can't live with 
waiting till all the idelayctrls come on line, or c) are doing something 
where you have different reference clocks (why would you do this?) or 
different resets for the idelayctrls, then I think the added power 
consumption and the big and gate are a very small price to pay for the 
simplicity of the un LOC'd instancing.

Article: 112336
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Mon, 20 Nov 2006 22:06:35 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> John Larkin wrote:
> 
> 
>>
>> They should back off this religious devotion to fully synchronous
>> logic and give us a couple of dozen programmable true delay elements,
>> scattered about the chip. But they won't because it's not politically
>> correct, and because they figure that we're so dumb that we'd get into
>> trouble using them.
>>
>>
>> John
>>
> 
> Virtex4 has them.  They are the idelay elements, which give you 64 steps 
> of delay with 75ps granularity.

That's great, but for those of us using lower power [and on a lower 
budget ;) ] devices, I could wish for the tools to obey my requirements, 
but that would be a 'vendor specific solution' unless I could get 
Verilog / VHDL changed to have a keyword where the synthesis / PAR tools 
would understand that 'this is not to be optimised in any way' on a 
perhaps module basis, rather than on a global basis (WYSIWYG comes to mind).

I've even gone to the extent of specifically instantiating primitives, 
and PAR *still* optimises them out, even though there's plenty of room 
for the logic, and I really wanted to do it that way for various 
reasons. I do not want the tools to try and think for me; software that 
tries to be that smart only succeeds in being dumb. I have written a 
*lot* of software, and I learned that lesson the hard way.

As John already noted, the fervency around synchronous design is almost 
religious. As I note in another post, it's preferable *most of the 
time*, but there are times it actually prevents me from doing things 
properly. One could hope the FPGA vendors and tool vendors might listen 
to experienced pure hardware designers on this.

Cheers

PeteS

Article: 112337
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Mon, 20 Nov 2006 22:49:29 GMT
Links: << >>  << T >>  << A >>
petrus bitbyter wrote:
> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schreef in 
> bericht news:1ejvl2d3j9tj96emac307rtjfr2l4o40q1@4ax.com...
>> On Sun, 19 Nov 2006 00:24:34 GMT, PeteS <peter.smith8380@ntlworld.com>
>> wrote:
>>
>>> John Larkin wrote:
>>>> On Sat, 18 Nov 2006 23:23:30 GMT, PeteS <peter.smith8380@ntlworld.com>
>>>> wrote:
>>>>
>>>>> When I do pure hardware I do not have to try and figure out what the
>>>>> hell was done to implement my statements.
>>>>>
>>>>> This was a major issue on a design I did about 4 years ago where I
>>>>> interfaced an upstream bus to the busses on 6 devices (with a lot of
>>>>> other stuff) and the synthesis / PAR etc kept optimising away certain
>>>>> things that were there to maintain the timing. The response I got was
>>>>> 'well, use pure synchronous design' but in this case it was simply not
>>>>> possible (am issue I am sure you'll understand).
>>>> Yup, this *is* the real world. We recently had to do a clock-edge
>>>> deglitcher, using delay elements. It couldn't be synchronous, because
>>>> we were, well, deglitching the clock! Ditto stuff like charge-pump
>>>> phase detectors, where you really need exactly what you need, delays
>>>> and all.
>>>>
>>>>
>>>>> I once deliberately did a DeMorgan transform by hand because I did nto
>>>>> trust the tool to do it right. (Code available on request ;) )
>>>>>
>>>>> Cheers
>>>>>
>>>>> PeteS
>>>>
>>>> One thing you can do is add a pulldown to a pin (or ground it) and
>>>> call that signal ZERO or something. Then just OR it with things to
>>>> create new, buffered, delayed things. If you need more, run it through
>>>> a shift register and create ZERO1, ZERO2, etc. The compiler can't
>>>> optimize them out!
>>>>
>>>> So the FPGA software people ought to provide us an irreducible ZERO
>>>> without wasting a pin, or a buffer that stays a buffer always.
>>>>
>>>> So, is there a block of logic so complex that the compiler can't
>>>> figure out that it indeed will always output a zero? Maybe the MSB of
>>>> a thousand-year counter, but that wastes flops. Maybe some small but
>>>> clever state machine that always makes zero but is too tricky to be
>>>> optimized?
>>>>
>>>> John
>>>>
>>> As noted, I once did a DeMorgan transform by hand (simple one too) and
>>> it materially changed the compiled output. (For those who understand the
>>> transform, don't get upset at the comments; they were there for people
>>> who _didn't_).
>>>
>>> Here it is:
>>>
>>> ******************************
>>>
>>> else begin
>>> cs0 <= cs_l; // make a direct copy of the cs signal
>>> cs1 <= (cs0 | cs_l); // Note - this uses a DeMorgan transform
>>> // the formula really is this : cs1 <= !(!cs_l & !cs0)
>>> // rather than cs1 <= (!cs_l & !cs0)
>>> // Note the extra output inversion, which renders an
>>> // inversion unnecessary
>>> // DeMorgan's theorem is this
>>> // <y = !a & !b> === <!y = a | b>
>>> // i.e. invert all signals and change and to or and vice
>>> // versa. Note this works only on basic functions
>>> // ( &, |, ! ) (AND, OR, INVERT)
>>> // for a valid select, we need two consecutive samples of
>>> // cs_l low. Latch a low, then look at the latch and the
>>> // signal on the pin. If both are low, cs1 goes low. If
>>> // either are high (glitch, runt pulse) then cs1 stays high
>>> // We trigger on internal cs (cs1) going low
>>> // Why did I use it? Because it requires no inverters and
>>> // therefore saves me a gate delay by simply using a LUT
>>> // without inversion
>>> //
>>> // Of course, the tools *might* do this, but I can't
>>> // guarantee it, so I'll *****ing so it myself.
>>> end
>>> *****************************************
>>>
>>> Cheers
>>>
>>> PeteS
>> They should back off this religious devotion to fully synchronous
>> logic and give us a couple of dozen programmable true delay elements,
>> scattered about the chip. But they won't because it's not politically
>> correct, and because they figure that we're so dumb that we'd get into
>> trouble using them.
>>
>>
>> John
>>
> 
> Well, synchronous design is easier and more understandable then 
> asynchronous. So the "specialists" tell the world synchronous design is the 
> only way rather then confess they are unable to make reliable asynchronous 
> ones. And let's be honest. A lot of old asynchronous designs are real 
> nightmares of critical race conditions, ad hoc inserted RC delays, glitches 
> and tricks. Good asynchronous engineering is rare and was rare even in the 
> days synchronous design was not yet invented. (Practised may be the better 
> word.)
> I ever was asked to "debug" a time critical circuit. Looking at the 
> asynchronous circuit which failed only once a week or so and reading the 
> full page of explanations about the inner workings I discarded the whole 
> design, doubled the clock frequency and made a rock solid synchronous 
> circuit. They were almost disappointed it was that "eas". I could have made 
> disciples for "synchronous only" but I'm not a true believer myself.
> Times they are a changing. I heard rumours asynchronous design has a revival 
> as it can be used to build faster circuits. There should be special software 
> for it, meant to design processors and the like. It's those software that 
> makes me shiver. When the first micros hit the market, an engineer 
> complained that those programmers used lots of extra space. He would have 
> been fired by using only one percent of that number in extra gates. (Nothing 
> to do with old uncle Billy :) Things did not grow better ever since but the 
> real bad development is the habit of those programmers to think and make 
> decisions for me. I really hate that. Almost all of these programmers have a 
> theoretical background in "software engineering". Ever visited such a 
> college with lots of computers, tens of masters and hundreds of students and 
> no one could handle a soldering iron. There was none in the whole place. An 
> assistant brought his own one from home when he needs to repair a cable. 
> None of those "engineers" ever wrote bugfree software, but expect hardware 
> designs to be it. Nevertheless, if something goes wrong, it's inevitable a 
> hardware failure. I ever had technicians to exchange hardware seven times 
> before they stopped to deny it to be a bug in the software. Another time one 
> of my collegues disassembled a floppy driver to prove it did not met the 
> drive specifications. (It could not format a floppy and they insisted we 
> used the wrong brand of floppy although we tried every brand we could lay 
> our hands on.) They complained about the disassembly rather then admit their 
> own failure.


> 
> Well, maybe we're doomed. Maybe I'm going to write software. What's worse? 
> :)
> 
> petrus bitbyter 
> 
> 

_Me_ going back to software!

Muahahaha

Cheers

PeteS

Article: 112338
Subject: Re: Need examples/instruction: use of altpll_reconfig (Altera)
From: "Subroto Datta" <sdatta@altera.com>
Date: 20 Nov 2006 15:11:47 -0800
Links: << >>  << T >>  << A >>
Hi Bob,
  Please see if the user guide available at
http://www.altera.com/literature/ug/ug_altpll_reconfig.pdf
answers your questions. If it does not do sen me email.

Hope this helps,
Subroto Datta
Altera Corp.

On Nov 20, 5:46 am, Bob <rjmy...@raytheon.com> wrote:
> For some reason, I'm not getting how to create the various
> .mif files to initialize enhanced PLLs with Quartus II.
> I'm trying to target a Stratix II device.  The situation that
> I'm in will require me to reconfigure the PLL's divisors
> dependent  upon the state of an input pin on the FPGA.
>
> Anyone got a step-by-step set of instructions that cleary
> describe how to do this?


Article: 112339
Subject: Re: Need examples/instruction: use of altpll_reconfig (Altera)
From: "Subroto Datta" <sdatta@altera.com>
Date: 20 Nov 2006 15:13:33 -0800
Links: << >>  << T >>  << A >>
Hi Bob, also check out http://www.altera.com/literature/an/an367.pdf

which will have more Stratix II specific information on this topic.
Hope this helps,
Subroto Datta
Altera Corp.

On Nov 20, 3:11 pm, "Subroto Datta" <sda...@altera.com> wrote:
> Hi Bob,
>   Please see if the user guide available athttp://www.altera.com/literature/ug/ug_altpll_reconfig.pdf
> answers your questions. If it does not do sen me email.
>
> Hope this helps,
> Subroto Datta
> Altera Corp.
>
> On Nov 20, 5:46 am, Bob <rjmy...@raytheon.com> wrote:
>
>
>
> > For some reason, I'm not getting how to create the various
> > .mif files to initialize enhanced PLLs with Quartus II.
> > I'm trying to target a Stratix II device.  The situation that
> > I'm in will require me to reconfigure the PLL's divisors
> > dependent  upon the state of an input pin on the FPGA.
>
> > Anyone got a step-by-step set of instructions that cleary
> > describe how to do this?- Hide quoted text -- Show quoted text -


Article: 112340
Subject: Re: 8080 FSGA model in an FPGA
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Mon, 20 Nov 2006 17:24:57 -0600
Links: << >>  << T >>  << A >>


JJ wrote:

>Every transistor counts whether it is a logic pull down (enhancemenet)
>or load (depletion). or clocked pass gate or even any capacitors which
>are usually free in area, its always distinct mos gate area. A
>depletion transitor is usually used as a constant current source rather
>than resistor, but as a resistor if the gate has fixed voltage.
>Typically for all static logic I would expect 3 logic and 1 load device
>on avg, but in this case most logic was precharged and conditionally
>discharged. Only the register flops had to be static.
>
>Since it had a 12v supply, it may have not had any depletion device
>loads, using long thin enhacment t's s as loads, mucho area and power
>and poor speed. The 8085, Z80 definitely had depletion and hidden
>poly-diff contacts to simplify everthing.
>
>I did have the schematic for the datapath area and thats about 30% of
>the chip. IIRC maybe 8-10 registers included umdocumented, each was
>probably a 4t asymetric cross couple with an extra t to read and and t
>for write. An ALU bit slice is probably 20-30 t's so 1 datapath
>bitslice is probably <100 devices so <1000 for the whole math area..
>
>Remember that t logic (see Mead Conway) can do alot for a few devices.
>2e1d devices makes a 2 input  nor or nand or poor mans xor and the ALU
>used only a few per bit. The carry was a precharged manchester pass
>gate with conditional discharge, the P,G terma probably reused a mux
>box function generator  (a bit like a LUT) that also did the logic
>operations.
>
>Also the whole thing was state sequential, no pipelining so many cycles
>used to do trivial operations. The entire schematc could have easily
>been drawn on 1 large sheet of paper if need be.
>
>  
>
Even as a gate-level schematic it would be a pretty busy sheet of paper!
I hope the OP is not going to go through with this project.  There is 
Seymour
Cray's first computer at the Computer History Museum, a big box with
hundreds of small boards he etched by hand in his garage.  Of course, he
got to sell the thing to the Navy when he finished it.  The OP is going 
to go
through the same level of effort, but he won't make a dime on it.

I'm reminded of the guy in Germany, I think, who built a digital clock using
vacuum tubes for all the amplifying elements.  Even using some very tricky
designs with multi-grid tubes, it was a monster with over 100 tubes.

Jon

Jon


Article: 112341
Subject: Re: Platform USB Cable and Windows XP Pro x64
From: Eric Smith <eric@brouhaha.com>
Date: 20 Nov 2006 16:04:40 -0800
Links: << >>  << T >>  << A >>
Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> writes:
> Unfortunately, the drivers and iMPACT software for 64 bit platforms
> will not be available until the next release of ISE due in Jan, 2007

If that includes 64-bit Linux, it's great news.  :-)

Article: 112342
Subject: Re: memory init in Altera bitfiles, (like data2mem) is it possible?
From: "radarman" <jshamlet@gmail.com>
Date: 20 Nov 2006 16:12:26 -0800
Links: << >>  << T >>  << A >>
kempaj@yahoo.com wrote:
> On Nov 17, 6:50 am, "Antti" <Antti.Luk...@xilant.com> wrote:
> > I just cant belive it, its one of the most useful things for the FPGA
> > SoC designs, and its just not there? I really doesnt have time or fun
> > to reverse engineer the .SOF format only to be able write the data2sof
> > utility for Altera.
>
> Antti,
>
> Others have commented on the general-purpose case, but since you made a
> specfiic reference to processors its worth discussing the soft-CPU flow
> for
> placing your code/data into onchip ram.
>
> No, this wasn't forgotten. In fact, support for doing this has been
> around about
> as long as Nios I/Nios II have been (6+ years now?). There are even
> several ways
> to accomplish the task:
>
> - If you are building your Nios II software in the IDE, it will take
> any coce/data linked into
> an onchip memory peripheral and use the elf2hex command to create a hex
> initialization
> file. The onchip RAM RTL generated by SOPC Builder is written out to be
> initialized this
> way; if you compile your design w/o any software having been built,
> memory will be left
> un-initialized, while if you first compile your software and then
> (re)compile in quartus,
> the .hex file(s) are used to initialize the memories.
>
> If you turn on verbose command line output from the IDE (window ->
> preferences -> nios II),
> you'll see the precise commands fly by on the console for future
> reference and command-
> line use.
>
> - Although the IDE-based flow doesn't do this now, you can even update
> your .sof
> file very quickly with onchip ram contents without risk of triggering
> an entire
> re-compile. I cannot recall the exact syntax of the command but I
> believe the compilation
> step is the Quartus Assembler (quartus_asm)
>
> - The "small" example design that ships with Nios II uses the above
> IDE-based
> method to initialize onchip RAM and as I recall the design's readme and
> other
> literature discuss this.
>
> Note that there are exclusions to what I've said, specifically for the
> types of
> onchip ram (m-ram blocks in Stratix, Stratix II) that cannot be
> initialized until
> runtime. The wizard to create an onchip ram in SOPC Builder allows you
> to
> choose which type of ram block will be used, if you desire, to ensure
> that you
> can pre-initialize contents if that is what you need to do.
>
> Jesse Kempa
> Altera Corp.
> jkempa --at-- altera --dot-- com

This is all well and good, but even with smart compilation turned on,
things don't work quite as well as they should. I'm designing my own
CPU core, so I'm not using NIOS, but I still need to be able to update
BRAM's with new program code.

I've already worked around (sort of) the fact that for some reason,
Quartus won't properly update a BRAM from a .hex file. (.hex files work
fine for compilation, but not a mif/hex update. So, I bring my .hex
file into Quartus, and save it as a .mif file.  This is annoying, since
I can no longer automate the whole build process. At some point, when I
get irritated enough, I'll write a program that converts hex to mif
correctly, but I haven't had the time for much extra programming
lately.

However, the MORE irritating problem I've run into is that if I repeat
the mif/hex update process a second time, changing only the .mif file,
Quartus launches into a full recompile anyway. This is a bit
frustrating, since the "hardware" is stable at this point. I just need
to test software. Perhaps I've missed something, but I've yet to find a
way to avoid the full recompile on the second update.

Maybe this works correctly in the NIOS flow, but I don't have that tool
available. I did try the NIOS eval, though, and I didn't see any new
tools in it that looked like they would solve my problem.


Article: 112343
Subject: Re: board - T562.jpg
From: Eric Smith <eric@brouhaha.com>
Date: 20 Nov 2006 16:35:09 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:
> Virtex4 has them.  They are the idelay elements, which give you 64
> steps of delay with 75ps granularity.

One step closer to a synthesizeable VHDL "wait for 2 ns" statement!
Not that I think it's a good idea, but newbies are always asking
for it.  :-)

Article: 112344
Subject: Missing module : XFFT_V3_1 Verilog (not VHDL) module
From: "Vitaliy" <m.vitaliy@gmail.com>
Date: 20 Nov 2006 16:46:11 -0800
Links: << >>  << T >>  << A >>
Hello,

Does anyone know if XFFT_V3_1 Verilog (not VHDL) module (normally found
in C:\Modeltech_xe_starter\xilinx\verilog\XilinxCoreLib_ver) exists? It
was not shipped with ISE7.1i (I have noticed a few people in newsgroups
asking similar question), I got the update from Xilinx site but still
no luck. If you know, can you please point me to where to
-download it
-or compress and email it to me at vmykhayl@ee.ryerson.ca.

Regards,
Vitaliy

PS. The error message:
# vsim -L xilinxcorelib_ver -L unisims_ver -lib work -t 1ps
design_top_tb_tf glbl
# Loading work.design_top_tb_tf
# Loading work.design_top
# ** Warning: (vsim-3009) [TSCALE] - Module 'design_top' does not have
a `timescale directive in effect, but previous modules do.
#         Region: /design_top_tb_tf/uut
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.IBUFG
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.DCM
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.dcm_clock_divide_by_2
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.dcm_maximum_period_check
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.dcm_clock_lost
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.BUFG
# Loading work.my_radix2_xfft1024
# ** Error: (vsim-3033) my_radix2_xfft1024.v(135): Instantiation of
'XFFT_V3_1' failed. The design unit was not found.
#         Region: /design_top_tb_tf/uut/U3
#         Searched libraries:
#
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/xilinxcorelib_ver
#
C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver
#             work


Article: 112345
Subject: Re: 8080 FSGA model in an FPGA
From: Ray Andraka <ray@andraka.com>
Date: Mon, 20 Nov 2006 19:53:21 -0500
Links: << >>  << T >>  << A >>
Jon Elson wrote:


Some people have way too much time on their hands!

Article: 112346
Subject: Re: board - T562.jpg
From: Ray Andraka <ray@andraka.com>
Date: Mon, 20 Nov 2006 20:05:01 -0500
Links: << >>  << T >>  << A >>
PeteS wrote:

> Ray Andraka wrote:
> 
>> John Larkin wrote:
>>
>>
>>>
>>> They should back off this religious devotion to fully synchronous
>>> logic and give us a couple of dozen programmable true delay elements,
>>> scattered about the chip. But they won't because it's not politically
>>> correct, and because they figure that we're so dumb that we'd get into
>>> trouble using them.
>>>
>>>
>>> John
>>>
>>
>> Virtex4 has them.  They are the idelay elements, which give you 64 
>> steps of delay with 75ps granularity.
> 
> 
> That's great, but for those of us using lower power [and on a lower 
> budget ;) ] devices, I could wish for the tools to obey my requirements, 
> but that would be a 'vendor specific solution' unless I could get 
> Verilog / VHDL changed to have a keyword where the synthesis / PAR tools 
> would understand that 'this is not to be optimised in any way' on a 
> perhaps module basis, rather than on a global basis (WYSIWYG comes to 
> mind).
> 
> I've even gone to the extent of specifically instantiating primitives, 
> and PAR *still* optimises them out, even though there's plenty of room 
> for the logic, and I really wanted to do it that way for various 
> reasons. I do not want the tools to try and think for me; software that 
> tries to be that smart only succeeds in being dumb. I have written a 
> *lot* of software, and I learned that lesson the hard way.
> 
> As John already noted, the fervency around synchronous design is almost 
> religious. As I note in another post, it's preferable *most of the 
> time*, but there are times it actually prevents me from doing things 
> properly. One could hope the FPGA vendors and tool vendors might listen 
> to experienced pure hardware designers on this.
> 
> Cheers
> 
> PeteS

If you really feel the need for async design, it can be done with utmost 
care on an FPGA, but such a design has to take into account the routing 
delays.  The tools do not support specifying the routing delays beyond 
that needed to satisy synchronous operation, and for a very good reason 
(I'll address that in a moment).  You can keep the tools from optimizing 
out pieces you need through addition of keep attributes.  You can also 
instantiate primitives, which the tools generally do not remove (but you 
need to be careful with simple inversions or buffers), or you can create 
routed macros with FPGA editor.  The hooks are there for manually doing 
your async design, and I have used them on the rare occasion.  It is 
tedious and error prone, but everything you need to do it is there.

That said, the FPGAs and tools are targeted to the sync design audience, 
as that is the bread and butter of the industry.  The analysis and 
design is far easier to get correct with synchronous design rules, and 
as a result the tools are far easier to design and use for those cases. 
  Since the synchronous design domain represents the large majority of 
all digital design, and the tools for doing it are lower hanging fruit 
than what is required for async design, it is natural the FPGA vendors 
only target that market, and to not have any interest in the async 
market.  The cost to entry is too high: tools are much harder to design 
and verify, there are many more gotchas that need to be covered and 
tested for, there is a potential for far more technical support needs, 
and on top of all that a market that is less than a percent of the total 
market.  Why would any sane vendor even pursue that when there are so 
many other easier to obtain ways to make money?

Article: 112347
Subject: What's wrong with my tcl example in Quartus?
From: "fl" <rxjwg98@gmail.com>
Date: 20 Nov 2006 19:43:22 -0800
Links: << >>  << T >>  << A >>
Hi,
I am new to tcl and quartus. When I try to follow the tcl example on
page 2-2, Quartus II handbook, vol. 2, I cannot pass the second step,
i.e. fitter, see the following. At the same directory, GUI does pass
well. I don't know what is wrong. Can you help me out? Thank you very
much.












# quartus_fit filtref --part=EP1C12Q240C6 --fmax=80MHz --tsu=8ns
Info:
*******************************************************************
Info: Running Quartus II Fitter
    Info: Version 6.0 Build 202 06/20/2006 Service Pack 1 SJ Web
Edition
    Info: Copyright (C) 1991-2006 Altera Corporation. All rights
reserved.
    Info: Your use of Altera Corporation's design tools, logic
functions
    Info: and other software and tools, and its AMPP partner logic
    Info: functions, and any output files any of the foregoing
    Info: (including device programming or simulation files), and any
    Info: associated documentation or information are expressly subject

    Info: to the terms and conditions of the Altera Program License
    Info: Subscription Agreement, Altera MegaCore Function License
    Info: Agreement, or other applicable license agreement, including,
    Info: without limitation, that your use is for the sole purpose of
    Info: programming logic devices manufactured by Altera and sold by
    Info: Altera or its authorized distributors.  Please refer to the
    Info: applicable agreement for further details.
    Info: Processing started: Mon Nov 20 22:33:28 2006
Info: Command: quartus_fit filtref --part=EP1C12Q240C6 --fmax=80MHz
--tsu=8ns
Info: Selected device EP1C12Q240C6 for design "filtref"
Info: Fitter is performing a Standard Fit compilation using maximum
Fitter effort to optimize design performance
Error: Can't place node "clk" -- illegal location assignment PIN_G1
Error: Can't fit design in device
Error: Quartus II Fitter was unsuccessful. 2 errors, 0 warnings
    Error: Processing ended: Mon Nov 20 22:33:30 2006
    Error: Elapsed time: 00:00:02
child process exited abnormally
#


Article: 112348
Subject: Re: board - T562.jpg
From: joseph2k <quiettechblue@yahoo.com>
Date: Tue, 21 Nov 2006 03:50:10 GMT
Links: << >>  << T >>  << A >>
John  Larkin wrote:

> On Sat, 18 Nov 2006 17:58:50 GMT, PeteS <peter.smith8380@ntlworld.com>
> wrote:
> 
>>John Larkin wrote:
>>> On Sat, 18 Nov 2006 11:30:03 GMT, PeteS <peter.smith8380@ntlworld.com>
>>> wrote:
>>> 
>>>> John Larkin wrote:
>>>>> This is the thing I'm working on this month. It's a delay generator,
>>>>> with an MC68332 uP on the back side that manages things. One of my
>>>>> guys quit, leaving behind about 14 klines of nasty, buggy code, so I
>>>>> thought it over for about 18 seconds and tossed it and started over
>>>>> from scratch. I'm workin with another guy who is re-doing the nasty,
>>>>> buggy FPGA design, ditto. He says bad things about the V8.2/SP3 Xilinx
>>>>> WebPack software.
>>>>>
>>>>> The application program is in flash, soldered down, and we're going to
>>>>> include a flash boot-block thing that lets you reflash the app code
>>>>> through the serial or ethernet ports, to upgrade the firmware. That's
>>>>> sort of mind-boggling, since the flash which holds this boot program
>>>>> disappears from the uP bus while it's being erased or programmed.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>> That's an interesting non-ortho arrangement :)
>>>>
>>>> On Webpack 8.2 SP3, I am afraid he's right. There have been some
>>>> rumblings on comp.arch.fpga about it recently, and I 'upgraded' to it
>>>> for my latest design, and then it would not process 3 previous designs,
>>>> although those have no errors I can see. Xilinx claimed it had
>>>> 'tightened up' certain things, but it caused me some grief because
>>>> those designs are the basis for a number of things where the FPGA code
>>>> is designed to in-system upgradeable should some new feature be
>>>> requested. I eventually re-installed (from an old full download) 7.1
>>>> for those projects.
>>> 
>>> Yeah, I wish people would stop breaking things, and stay absolutely
>>> backwards-compatible to existing designs. FPGA were supposed to make
>>> hardware design easier, and then they sent in an army of programmers
>>> to replace hardware problems with software nightmares.
>>> 
>>> The *service pack* is a 300 megabyte download.
>>> 
>>>> I've done the reprogrammable flash thing myself and I definitely concur
>>>> it _can_ get a little hairy.
>>>>
>>>> Wish you the best of luck getting the design fully operational. What
>>>> are the specs?
>>> 
>>> Here it is. Fortunately, the hardware is in good shape, so all we have
>>> to do is pound the firmware and fpga into submission. Soon.
>>> 
>>> http://www.highlandtechnology.com/DSS/T560DS.html
>>> 
>>> 
>>> John
>>> 
>>Nice specs indeed.
>>
>>If I had the money, I'd want one ;)
>>
>>Cheers
>>
>>PeteS
> 
> But hey, this is a revelation:
> 
> Hardware design has always been comforting because it is direct,
> simple, visible, wysiwyg, physical, and generally reliable. The tools,
> oscilloscopes and such, are approachable and dependable. I can use a
> 30-year old tube-type TEK oscilloscope to debug the most modern analog
> or digital circuits, without downloading and installing service packs.
> 
> Software is abstract, indirect, bizarre, and unreliable. The tools are
> buggy, bloated, always changing, unpredictable, pig slow, and seldom
> backwards-compatible. I can't use current-gen tools to edit a 2-year
> old FPGA design, and I'm lucky if I can somehow still find and run the
> older tools.
> 
> So, FPFAs, VHDL, and the associated software tools are the trojan
> horse that's finally letting the software people get revenge, finally
> allowing them to force us hardware designers depend on (and endlessly
> pay for) their bizantine and unreliable methodologies, to trap us in
> the gotta-upgrade-but-every-generation-has-more-new-bugs loop.
> 
> And the new Windows-based scopes and logic analyzers, of course...
> same idea.
> 
> John

Come to the open source side John.

-- 
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

Article: 112349
Subject: Re: board - T562.jpg
From: joseph2k <quiettechblue@yahoo.com>
Date: Tue, 21 Nov 2006 04:11:02 GMT
Links: << >>  << T >>  << A >>
Spehro Pefhany wrote:

> On Sat, 18 Nov 2006 12:24:16 -0800, the renowned John  Larkin
> <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
> 
>>But hey, this is a revelation:
>>
>>Hardware design has always been comforting because it is direct,
>>simple, visible, wysiwyg, physical, and generally reliable. The tools,
>>oscilloscopes and such, are approachable and dependable. I can use a
>>30-year old tube-type TEK oscilloscope to debug the most modern analog
>>or digital circuits, without downloading and installing service packs.
>>
>>Software is abstract, indirect, bizarre, and unreliable. The tools are
>>buggy, bloated, always changing, unpredictable, pig slow, and seldom
>>backwards-compatible. I can't use current-gen tools to edit a 2-year
>>old FPGA design, and I'm lucky if I can somehow still find and run the
>>older tools.
>>
>>So, FPFAs, VHDL, and the associated software tools are the trojan
>>horse that's finally letting the software people get revenge, finally
>>allowing them to force us hardware designers depend on (and endlessly
>>pay for) their bizantine and unreliable methodologies, to trap us in
>>the gotta-upgrade-but-every-generation-has-more-new-bugs loop.
>>
>>And the new Windows-based scopes and logic analyzers, of course...
>>same idea.
>>
>>John
> 
> How about programs such as Solidworks that are only one-way upward
> compatible. I.e. you can open a part or assembly file created in SW
> 2005 with SW 2006 but once you save it in 2006 it cannot ever be
> opened again in 2005 (or 2004, or 2003 etc.). Thus forcing everyone to
> upgrade...
> 
> 
> Best regards,
> Spehro Pefhany

Do you not have a disciplined backup approach?  You can always get a 2005 or
2004 model and the SW to work it with a disciplined backup framework.

-- 
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller



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