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 112400

Article: 112400
Subject: Re: What's wrong with my tcl example in Quartus?
From: "fl" <rxjwg98@gmail.com>
Date: 21 Nov 2006 13:30:54 -0800
Links: << >>  << T >>  << A >>
Thanks, you are right. The example from the handbood is wrong.

Alan Nishioka a =E9crit :

> fl wrote:
> > 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
>
> Well I haven't used Altera for a while, but it looks like an
> EP1C12Q240C6 is a 240 pin PQFP and doesn't have a pin G1.
>
> Either you need to change the part or you need to change the pin.
>=20
> Alan Nishioka


Article: 112401
Subject: Re: memory init in Altera bitfiles, (like data2mem) is it possible?
From: dkarchmer@gmail.com
Date: 21 Nov 2006 13:37:35 -0800
Links: << >>  << T >>  << A >>
Antii,

My reply was intended for radarman who seems to be trying to simply
update the "db" with the modified HEX files, to later re-create the SOF
with quartus_asm.

As for your original email, you are correct we do not have a way to
update the SOF directly. Our flow assumes you are willing to use the
"db" as the input. All I can say is that I am personally not aware of
such request (until now).

Your feedback is well received.

-David Karchmer
 Altera

Antti wrote:
> dkarchmer@gmail.com schrieb:
>
> > Try the following from the command-line:
> >
> >    quartus_cdb <rev> --update_mif
> >    quartus_asm <rev>
> >
> > where <rev> is the base name of your QSF file (i.e. the revision).
> >
> > The --update_mif should take the post-fit results and update any MIF
> > and/or HEX file(s). You then run the assembler to re-generate the SOF.
> > So, at least from the command-line, you do not need to do a full
> > compile and you do not need smart recompile.
> >
> > If this does not work with HEX files (as it should), please file a
> > service request or send me an email as we would need to debug and fix
> > this. Thanks,
> >
> > -David Karchmer
> >  Altera
> >
>
> dont worry so much - Xilinx has been fixing issues with their data2mem
> for years and they still have not managed to get it right.
>
> well data2mem like tool is completly missing in Altera flow so Altera
> cant have it wrong (as it is missing)
> 
> 
> Antti


Article: 112402
Subject: Spartan 3E-Kit
From: spartanius@arcor.de
Date: 21 Nov 2006 13:49:57 -0800
Links: << >>  << T >>  << A >>
I found the thread about this kit but cannot write there, since it is
more than 60 days old.

I am seeking for an empty or small project to start with the xilinx
ide. Of course I found the sample projects, but a) they are too complex
IMO (i do not need the pico blaze yet ) and b) I am having difficulties
in creating a complete and working project from out of the given files.

To be honest, I am afraid of using a wrong configuration - esspeciall
pin files - and then ruin my fpga!

So if anybody has an "empty" project with correct settings (like unused
pins z) and /or "z" definitions for the board (i think it is something
as an ucf) I was happy if he could send me that.

Thanks in advance


Article: 112403
Subject: Re: EDK 8.2 Block RAM error
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 21 Nov 2006 17:02:12 -0500
Links: << >>  << T >>  << A >>
> 1 same size rquirement is BS, the tool should tolerate also different
> sized blocks

It should... however it doesn't....

> 2 and.. same size blocks dont work either, only first one gets PLACED,
> second stays unprocessed
>
> so its just another Xilinx bug,

Well, I do have a V4 design, which uses 4 consecutive 32KB BRAM blocks each
attached through an individual PLB_BRAM controller and it works (last tried
in 8.1)... Perhaps you are trying to do something more advanced...


/Mikhail



Article: 112404
Subject: Re: Spartan 3E-Kit
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 21 Nov 2006 23:13:16 +0100
Links: << >>  << T >>  << A >>
spartanius@arcor.de wrote:

> To be honest, I am afraid of using a wrong configuration - esspeciall
> pin files - and then ruin my fpga!

You can copy the UCF definition from the PDF documentation and then set an
option (I forget which) in the IDE to ignore unconnected pins.

> So if anybody has an "empty" project with correct settings (like unused
> pins z) and /or "z" definitions for the board (i think it is something
> as an ucf) I was happy if he could send me that.

Not empty, but you can delete anything you don't need:

http://www.frank-buss.de/vhdl/spartan3e.html

Included on the web page: the non-intuitve steps required to synthesize it,
starting and use of iMPACT :-)

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

Article: 112405
Subject: Re: EDK 8.2 Block RAM error
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 21 Nov 2006 23:19:09 +0100
Links: << >>  << T >>  << A >>
"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag 
news:4shb3eFvrarsU1@mid.individual.net...
>> 1 same size rquirement is BS, the tool should tolerate also different
>> sized blocks
>
> It should... however it doesn't....
>
>> 2 and.. same size blocks dont work either, only first one gets PLACED,
>> second stays unprocessed
>>
>> so its just another Xilinx bug,
>
> Well, I do have a V4 design, which uses 4 consecutive 32KB BRAM blocks 
> each
> attached through an individual PLB_BRAM controller and it works (last 
> tried
> in 8.1)... Perhaps you are trying to do something more advanced...
>
>
> /Mikhail
>
>
hm, i have two 64K blocks on LMB bus, and only first one is updated in the 
BMM file :(
I dont think this is advanced use ?

Antti 



Article: 112406
Subject: Re: 8080 FSGA model in an FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 21 Nov 2006 14:19:24 -0800
Links: << >>  << T >>  << A >>
Grant Stockly wrote:
> > If you are just trying to build a trainer of some sort, wouldn't it be
> > easier to build a simulation that could show all the internal states?
> > It has got to be easier to do a simulation than a construction project
> > from transistors or even from CPLDs.
>
> I guess its because I'm in Alaska?  The largest state in the union
> mentality causes me to want to build a computer from transistors?  :)
>
> I just find it so interesting that it can be done.  Why not make a kit!
>  :)  Wouldn't a second box under the altair with a few hundred lights
> be neat to watch?
>
> I really want to build a computer from relays, and even priced out some
> nice ones on e-bay, but I am concerned about how long it would last
> before failing...

One type of computer that might actually be interesting to build of
relays and operate would be a time piece.  To keep the power
consumption down, you might use latching relays.  The contain a
permanet magnet that holds the contact in either state and a pulse from
the coil is required to change the state.  Each relay is then a FF.
The logic would be done by stringing relays in series or parallel to
form AND and OR functions (with or without inversions).  You could also
use diodes to form the logic if you want to save some space.  There are
some fairly minature relays available at around $5 or less.  We are
using some latching RF relays at that price.  They are about 15 x 10 mm
so a clock circuit might take up a square foot depending on the
density.  It would also tick every second with major noises on the
minutes and hours.

I am working on a relay controller circuit for an RF module and when I
do the test code, it will have a few options to sound out tap dancing
like music.  That should prove interesting and entertaining!


Article: 112407
Subject: Re: board - T562.jpg
From: Ray Andraka <ray@andraka.com>
Date: Tue, 21 Nov 2006 17:51:46 -0500
Links: << >>  << T >>  << A >>
PeteS wrote:
> Ray Andraka wrote:
> 
>> 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?
> 
> 
> Thanks for answering, Ray :)
> 
> I understand why the vendors don't specifically target the async market, 
> although I will say that the software developers who do the tools don't 
> always appear to truly understand hardware (it covers so many sins, I am 
> not surprised, nor is it a complaint, more an acknowledgment).

Yup, I agree here.  I really think the developers should be required to 
sit and use their tools on a design, but then they'd have to get up to 
speed on digital design first.

> 
> As to making money, that is, to a great extent in any market, dependent 
> on customer goodwill. Making primitives that won't be optimised away and 
> not protecting me from myself when I so ask will make me far more likely 
> to use such a vendor again, because they have listened to my 
> requirements, and responded that such things are avialble. I take the 
> responsibility if it goes wrong, *provided* I get proper timing output 
> data from the tools. I'm not asking for autoplacement and guaranteed 
> constraint mapping, just a report that tells me the various timing 
> elements - then it's up to me.

I'm not sure what you are looking for.  You can dump speedprint if you 
really want to know the timing of elements (can you still do this, I 
haven't in several years).  The timing of the logic is very well 
defined, but you'll also see that it varies depending on which pin is 
used.  The timing of the routing is the fly in the ointment, because it 
typically represents 50% or more of the total timing between flip-flops 
in a synchronous design, and that route timing is of course quite 
sensitive to the exact route taken as well as to placement of the logic. 
  Are you looking for a report of every route segment in the device? 
That is a huge report, not likely to be of much use.  The static timing 
analyzer will report the timing of each element in a path, but the 
problem is combinatorial loops break it.

Article: 112408
Subject: I2C "READ" Setup/Hold Requirement
From: "markus" <markus_1401@yahoo.com>
Date: 21 Nov 2006 14:54:49 -0800
Links: << >>  << T >>  << A >>
Hello

For the I2C read, the step by step, the algorithm is:

1). write slave address+write bit
2). write register address
3). write slave addres+read bit
4). read

After the end of step 2, and before step 3, you need to set the STA to
indicate the real read. Note that STA is indicated by transition of
HIGH to LOW on the SDA while SCL remains HIGH. I am wondering if there
is minimum wait time between step 2 and beginning of step 3?

Note that my design uses OpenCores' I2C (if it matters). Thanks.

Happy Turkey Day,
-M


Article: 112409
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 21 Nov 2006 22:59:45 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> PeteS wrote:
>> Ray Andraka wrote:
>>
>>> 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?
>>
>>
>> Thanks for answering, Ray :)
>>
>> I understand why the vendors don't specifically target the async 
>> market, although I will say that the software developers who do the 
>> tools don't always appear to truly understand hardware (it covers so 
>> many sins, I am not surprised, nor is it a complaint, more an 
>> acknowledgment).
> 
> Yup, I agree here.  I really think the developers should be required to 
> sit and use their tools on a design, but then they'd have to get up to 
> speed on digital design first.
> 
>>
>> As to making money, that is, to a great extent in any market, 
>> dependent on customer goodwill. Making primitives that won't be 
>> optimised away and not protecting me from myself when I so ask will 
>> make me far more likely to use such a vendor again, because they have 
>> listened to my requirements, and responded that such things are 
>> avialble. I take the responsibility if it goes wrong, *provided* I get 
>> proper timing output data from the tools. I'm not asking for 
>> autoplacement and guaranteed constraint mapping, just a report that 
>> tells me the various timing elements - then it's up to me.
> 
> I'm not sure what you are looking for.  You can dump speedprint if you 
> really want to know the timing of elements (can you still do this, I 
> haven't in several years).  The timing of the logic is very well 
> defined, but you'll also see that it varies depending on which pin is 
> used.  The timing of the routing is the fly in the ointment, because it 
> typically represents 50% or more of the total timing between flip-flops 
> in a synchronous design, and that route timing is of course quite 
> sensitive to the exact route taken as well as to placement of the logic. 
>  Are you looking for a report of every route segment in the device? That 
> is a huge report, not likely to be of much use.  The static timing 
> analyzer will report the timing of each element in a path, but the 
> problem is combinatorial loops break it.

I want to know the static timing, no more, and I am aware it varies from 
pin to pin (well, duh). I am not asking for all possible routes.

Here's something I would like; in the floorplanner - an identification 
of timing by route (single route only) so I could actually choose a 
specific signal route.

;and then lock it.

Do-able?

Cheers

PeteS

Article: 112410
Subject: Re: board - T562.jpg
From: Ray Andraka <ray@andraka.com>
Date: Tue, 21 Nov 2006 17:59:59 -0500
Links: << >>  << T >>  << A >>
PeteS wrote:

> 
> I want to know the static timing, no more, and I am aware it varies from 
> pin to pin (well, duh). I am not asking for all possible routes.
> 
> Here's something I would like; in the floorplanner - an identification 
> of timing by route (single route only) so I could actually choose a 
> specific signal route.
> 
> ;and then lock it.
> 
> Do-able?
> 
> Cheers
> 
> PeteS


Not in floorplanner, as floorplanner is a placement tool and is totally 
unaware of routing.  You can do that in FPGA editor if you manually 
route rather than using autoroute.  You can also create pre-routed 
macros this way.

Article: 112411
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 21 Nov 2006 23:06:07 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> PeteS wrote:
> 
>>
>> I want to know the static timing, no more, and I am aware it varies 
>> from pin to pin (well, duh). I am not asking for all possible routes.
>>
>> Here's something I would like; in the floorplanner - an identification 
>> of timing by route (single route only) so I could actually choose a 
>> specific signal route.
>>
>> ;and then lock it.
>>
>> Do-able?
>>
>> Cheers
>>
>> PeteS
> 
> 
> Not in floorplanner, as floorplanner is a placement tool and is totally 
> unaware of routing.  You can do that in FPGA editor if you manually 
> route rather than using autoroute.  You can also create pre-routed 
> macros this way.

Hmmm.... that opens up all sorts of new avenues (not to be told to the 
unwashed masses of course). Do those pre-routed macros get effectively 
locked? One would assume so, but I'll ask anyway.

Thanks!

PeteS

Article: 112412
Subject: Re: Spartan 3E-Kit
From: spartanius@arcor.de
Date: 21 Nov 2006 15:07:31 -0800
Links: << >>  << T >>  << A >>
thanks, but the synthesis sais "NgdBuild:755 - Line 7 in
'E:/xilinxprojekte/frankbuss/src/spartan3e.ucf':" for nearly all the
lines up to 200x. (?


Article: 112413
Subject: Re: board - T562.jpg
From: PeteS <peter.smith8380@ntlworld.com>
Date: Tue, 21 Nov 2006 23:08:36 GMT
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:
> John,
> 
> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
> news:1ejvl2d3j9tj96emac307rtjfr2l4o40q1@4ax.com...
>> 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.
> 
> I think the real problems are that:
> 
> 1) It'd be difficult (read: expensive) for them to provide reasonably accurate 
> delay elements.  With synchronous design, they just add a ring oscillator 
> somewhere and empirically determine how fast the thing will run, bin them 
> accordingly, and they're done!  For delay elements... well, what are the 
> options?  Laser trimming?  Non-volatile tapped delay lines?  Nothing that I 
> can think of that's dirt cheap.
> 
> 2) You're correct, they do figure that "you" [as a whole] will get into 
> trouble using them.  You -- personally -- clearly won't, but if you're running 
> a business it's clearly useful (to your bottom line!) to set up the system so 
> that you try to protect people who don't know what they're doing from blowing 
> their feet off.  That being said, this approach is often taken too far to not 
> only keep a couple of the more advanced "doors" closed, but to put locks on 
> them altogether.  I've seen software development tools go this route as 
> well -- they're perhaps improved and easier to use for novices, but actually 
> harder and less functional for experts.  These days I have to hold my tongue 
> rather than go around claiming things aren't "expert friendly," because it is 
> seen as an attack somehow on the less-than-expert users.  That's where the 
> political correctness BS comes into play!
> 
> 
> 
Attack my ass

If I can't gain complete access to the machine with a language, *I won't 
use it*. The fact that there are many who have no clue of what to do 
with it should not be an impediment to *my ability to develop solutions*.

Sounds like an ID Ten T error to me

Cheers

PeteS

Article: 112414
Subject: Re: Spartan 3E-Kit
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Tue, 21 Nov 2006 23:24:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
spartanius@arcor.de wrote:
> thanks, but the synthesis sais "NgdBuild:755 - Line 7 in
> 'E:/xilinxprojekte/frankbuss/src/spartan3e.ucf':" for nearly all the
> lines up to 200x. (?

I also got there very elaborated messages on my design today. After digging
some time, I realized, that nets "LOC"ed in the UCF did not exist in the HDL
sources or had typing errors. But why the hell doesn't the error message
tell that?

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 112415
Subject: CORDIC FM Demodulation
From: "ma" <ma@nowhere.com>
Date: Tue, 21 Nov 2006 23:30:19 GMT
Links: << >>  << T >>  << A >>
Hello,

     I know that it is possible to demodulate an FM signal using a CORDIC
ATAN core and the subtracting the current ouput of cordic from the last one.
But I can not understand how carrier frequency and sampling rate would
change it? What are the requirements? Where are the limitations?



Regards



Article: 112416
Subject: Re: timing constraints
From: dkarchmer@gmail.com
Date: 21 Nov 2006 15:41:40 -0800
Links: << >>  << T >>  << A >>
Kumar,

Please look at

http://www.altera.com/literature/hb/qts/qts_qii53004.pdf

Based on your baord requirements, you need to first spec your I/O
timing requirements, and once you have them, you can use the assignment
editor to enter the assignment. The document should help you understand
the assignments for you to figure out your spec.

As for an example for the assignment editor, here is one for Tsu

- From Column: You can either enter the clock reference or leave empty
- To Column: Enter the name of the pin you want to constraint
- Assignmane Name: "Tsu Requirement"
- Value: <value in ns>

When you are done, click "Start Timing Analysis" and you should see the
Tsu report show slack.

In your QSF file, you will see something like

set_instance_assignment -to mypin -name TSU_REQUIREMENT "5 ns"

Hope this helps,

-David Karchmer
 Altera

ram wrote:
> In the cyclone devices,
> How to set parameters like tco,tsu,th,tpd.I am not using any M4K RAMS
> or DSP blocks.I am using for LE_FF timing and LVTTl standards.I am not
> using fast corner analysis.I have to fix up hold violations of no 96 I
> referred cyclone II device data sheet DC and timing characteristics
> page 106-135.How to set this paramters.There are no examples for
> this.Can you provide examples for this.If you provide examples for this
> in assignment editor ,it will be useful for users
> kumar


Article: 112417
Subject: Re: board - T562.jpg
From: Ray Andraka <ray@andraka.com>
Date: Tue, 21 Nov 2006 18:48:53 -0500
Links: << >>  << T >>  << A >>
PeteS wrote:

> Ray Andraka wrote:
> 
>> PeteS wrote:
>>
>>>
>>> I want to know the static timing, no more, and I am aware it varies 
>>> from pin to pin (well, duh). I am not asking for all possible routes.
>>>
>>> Here's something I would like; in the floorplanner - an 
>>> identification of timing by route (single route only) so I could 
>>> actually choose a specific signal route.
>>>
>>> ;and then lock it.
>>>
>>> Do-able?
>>>
>>> Cheers
>>>
>>> PeteS
>>
>>
>>
>> Not in floorplanner, as floorplanner is a placement tool and is 
>> totally unaware of routing.  You can do that in FPGA editor if you 
>> manually route rather than using autoroute.  You can also create 
>> pre-routed macros this way.
> 
> 
> Hmmm.... that opens up all sorts of new avenues (not to be told to the 
> unwashed masses of course). Do those pre-routed macros get effectively 
> locked? One would assume so, but I'll ask anyway.
> 
> Thanks!
> 
> PeteS


Yes.  You can also generate routing directives that can go back into the 
ucf to direct routing, although those are specific to the location (ie, 
not hierarchical).

Article: 112418
Subject: ISE 8.2 & XC9500XL family
From: "Jozsef" <bit_vector@tvn.hu>
Date: 21 Nov 2006 16:02:21 -0800
Links: << >>  << T >>  << A >>
Hello,

 as many people over this world, I have a problem. The problem is the
connection beetween a CPLD and the WEBPACK ISE 8.2.03 software.
Simptoms like very static: I have an Parallel Cable III, the ISE
software, and a XC9500XL family CPLD. The Impact cannot recognise the
CPLD, for example a simple XC95144XL showed five unknown device in the
JTAG chain on automatic JTAG chain initialize. I' has been tried to add
the device manually, but there is not accepted as a result, because
Impact answers unknown device ID. I'm told each family because tried
with xc9536XL, simptoms are same.
The cable is OK, I using it to program other devices (for example,
XC3S400) on everyday.
On software side, tried an older software (Xilinx Foundation 4) to
program these devices, that programs all without problems.

 The question is what is the problem with ISE 8.2.03 ???


Article: 112419
Subject: Re: 8080 FSGA model in an FPGA
From: "Grant Stockly" <grant@stockly.com>
Date: 21 Nov 2006 16:19:07 -0800
Links: << >>  << T >>  << A >>
> One type of computer that might actually be interesting to build of
> relays and operate would be a time piece.  To keep the power
> consumption down, you might use latching relays.  The contain a
> permanet magnet that holds the contact in either state and a pulse from
> the coil is required to change the state.  Each relay is then a FF.
> The logic would be done by stringing relays in series or parallel to
> form AND and OR functions (with or without inversions).  You could also
> use diodes to form the logic if you want to save some space.  There are
> some fairly minature relays available at around $5 or less.  We are
> using some latching RF relays at that price.  They are about 15 x 10 mm
> so a clock circuit might take up a square foot depending on the
> density.  It would also tick every second with major noises on the
> minutes and hours.
>
> I am working on a relay controller circuit for an RF module and when I
> do the test code, it will have a few options to sound out tap dancing
> like music.  That should prove interesting and entertaining!

That is a pretty good idea.  Would you have to use vaccume tubes with a
crystal to generate the 1 second clock?  (to maintain period
technology)

Now you have my head spinning...Its a good thing I'm done with the
Altair!  :)

Before that I wanted to answer the question "What is the latency of a
ping to a relay based computer?"  My friends would hardly talk to me
about that one.  They think I'm crazy too.

ALL the relays need to be the clear ice cube kind with the LED to
indicate state.  Or a separate LED I guess.  I really like visual
things.  :)


Article: 112420
Subject: Re: Spartan-3E slice resources
From: "kunil" <kunilkuda@gmail.com>
Date: 21 Nov 2006 16:51:23 -0800
Links: << >>  << T >>  << A >>

Thank you..After I used xilinx's floorplan, I was able to fit it into 1
slice.

Eric Crabill wrote:
> Hello,
>
> What you expected is what the report said.  I think you may have
> misunderstood it.  It has used 1 out of 4656 slices.  The "Slice Flip Flops"
> count is count of  how many flip flops were used in your 1 slice.  The
> report could be a bit more clear, I think in the mapper report, this
> relationship is more obvious due to the use of indentation in the text.
> 
> Eric


Article: 112421
Subject: Re: board - T562.jpg
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 21 Nov 2006 17:36:55 -0800
Links: << >>  << T >>  << A >>
On Mon, 20 Nov 2006 22:06:35 GMT, PeteS <peter.smith8380@ntlworld.com>
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


We just solved a nasty problem with this:

A d-flop: D tied high; clocked from a pin, CE from internal gating
logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a
delay line back into its own async clear. When the input pin rises, if
CE permits, it makes a single clock pulse. Everything downstream is
"synchronous" in that it's clocked from this gadget.

The delay line is a chain of AND gates (with transparent latches
enabled in the logic cells, just to add a little more delay), with
each fed from the ff Q and also from the previous gate. This is a
delay line with a fast discharge mechanism when its input goes low, so
we don't have to wait for the 0 to propagate through, chasing the 1.

John


Article: 112422
Subject: Re: PCMCIA interface
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Tue, 21 Nov 2006 22:04:58 -0500
Links: << >>  << T >>  << A >>
Just one small clarification:

Expresscard is not "equivalent" to PCIe: the connector actually provides 
both PCIe x1 and USB 2.0 ports, allowing each Expresscard slot to house 
either PCIe or USB based devices... or possibly both at once, should 
someone find a need for that.

Since PCIe and USB are hotplug busses, they do not need the host 
controller glue logic Cardbus and PCMCIA required to bridge the void 
between hotplug cards and non-hotplug consumer PCI.

John Adair wrote:
> 
> Expresscard is mechanically incompatible and is basically a replacement
> for PCMCIA/Cardbus and is the laptop equivalent of PCI-E. It is very
> rapidly replacing PCMCIA/Cardbus in new laptops.
> 
> John Adair
> Enterpoint Ltd.
> 
> vasile wrote:
>> John Adair wrote:
>>> Even if you implement Cardbus (essentially PCI) rather than
>>> PCMCIA(essentially ISA) you won't get continuous 33MHz transfer other
>>> than short periods of time. ExpressCard format can go this fast
>>> providing the architecture behind it can support that data rate.
>> Hi John,
>> I didn't heard about this standard before. It's compatible with most
>> PCMCIA interfaces
>> available on laptops ? There is somewhere a documentation available ?
>>
>> thx,
>> Vasile

Article: 112423
Subject: Re: Spartan 3E-Kit
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 22 Nov 2006 04:17:49 +0100
Links: << >>  << T >>  << A >>
spartanius@arcor.de wrote:

> thanks, but the synthesis sais "NgdBuild:755 - Line 7 in
> 'E:/xilinxprojekte/frankbuss/src/spartan3e.ucf':" for nearly all the
> lines up to 200x. (?

I can't reproduce this with the ise\Spartan3E.ise project file. If you've
setup your own project, right-click on "Implement Design"->"Translate" and
enable "Allow Unmatched LOC Constraints", if it is Uwe referenced. Do you
use the latest version of ISE (help->about: 8.2.0.3i) ?

Another interesting source of errors: ISE saves local settings for your
projects in C:\Documents and Settings\YourName\Local
Settings\Temp\something-with-ise-and-your-project-name
Once I replaced the source files for my project, because I didn't want to
setup all the settings again, but it didn't worked until I deleted the
temporary files.

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

Article: 112424
Subject: Re: I2C "READ" Setup/Hold Requirement
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Tue, 21 Nov 2006 22:47:57 -0500
Links: << >>  << T >>  << A >>
Hi,

I have been having fun with I2C for a while. If you read the I2C specs, 
you will see that the same delays come up everywhere for any given bus 
speed.

For 400kbps, this magic number is 600ns: SCL and SDA pulses must be 
600ns wide minimum, a master should leave the bus idle for 600ns between 
transactions, SDA-to-SCL edges for start/stop should be at least 600ns 
apart, etc.

Since the condition between your #2 and #3 should be a 'restart', there 
should usually not be any extra delays needed there, other than the 
usual 600ns SDA-to-SCL for start/stop conditions. Then again, many I2C 
devices have quirks that must be dealt with on a case-by-case basis.

The opencores I2C master is somewhat odd: it seems that its designer 
forgot to provide some means of generating interrupts before the master 
outputs the ACK bit when reading a slave. Without this, the host has to 
divine whether or not the next byte received will be ACK'd. With that 
interrupt (and freezing SCL), the host would be able to make this (ACK) 
decision after receiving the byte.

markus wrote:
> Hello
> 
> For the I2C read, the step by step, the algorithm is:
> 
> 1). write slave address+write bit
> 2). write register address
> 3). write slave addres+read bit
> 4). read
> 
> After the end of step 2, and before step 3, you need to set the STA to
> indicate the real read. Note that STA is indicated by transition of
> HIGH to LOW on the SDA while SCL remains HIGH. I am wondering if there
> is minimum wait time between step 2 and beginning of step 3?
> 
> Note that my design uses OpenCores' I2C (if it matters). Thanks.
> 
> Happy Turkey Day,
> -M
> 



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