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
2019JanFebMar2019

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 126225

Article: 126225
Subject: Re: New Laptop for work
From: "HT-Lab" <hans64@ht-lab.com>
Date: Sat, 17 Nov 2007 10:31:02 GMT
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:d2fd7e80-2f5f-4366-b704-03fcee01bbfd@a28g2000hsc.googlegroups.com...
>I am looking at a low end Dell laptop, the Vostro 1500, as a new
> computer for work.  I may supplement this later with a new desktop
> unit for crunching FPGA designs,

Consider a small form factor PC, they are small enough to carry home and you 
get all the power of a desktop. The only disadvantage is that you can't use 
them at an airport :-)

> but I will also be using this laptop
> for this sort of work.  I am looking for advice on the differences in
> CPUs for FPGA work and anything else that is relevant.
>
> I know that parallel ports are going the way of the serial port and
> the dodo bird, but I can live with that.  Most tools are available as
> USB devices now.

Correct, if you need a parallel port just look on ebay for a low-cost PCMCIA 
parallel port card (don't buy a USB to Parallel port cable since they do not 
work with dongles and apparently download cables). Serial ports are no 
problem, I bought a 7 USB to serial port cable and it works perfectly ( I 
use it with Teraterm to connect to my prototype board).

>
> This particular computer comes with WindowsXP rather than Vista.  From
> what I have heard, that is an advantage.

Definitely, most EDA companies do not yet support Vista and if you don't 
care about wobbly windows then stick with XP. As suggested by Andy I would 
also recommend you set-up a dual boot with Linux. If you do this then I 
would recommend using Redhat or one of its clones like CentOS 4.4 (not 5). 
Linux is a great EDA environment although for some reason some EDA companies 
still like to charge extra for their Linux version. I would also suggest you 
keep your XP installation since you might nullify your warranty (completely 
brain-dead I know).

> But I notice that the
> internal bluetooth adapter is specific for XP and others from Dell are
> specific for Vista.  Any idea what is up with that?  Is there any
> significant advantage to using XP pro over XP home?
>
> This machine also has the "Intel(R) Integrated Graphics Media
> Accelerator X3100".  Is that just another way of saying "integrated
> video"?  Several of my other machines have had integrated video and it
> does seem to drag down the CPU noticeably.  Any idea if I will notice
> the drag on the Core 2 Duo?
> They also offer an Nvidia Gforce 8400 GS
> adapter for $100 and an 8600 for $200 more.  Any idea if these are
> worth it?  The 1500 says it has "VGA video output & S-Video".  Does
> that mean I can connect two monitors for dual display?

If you want more screen area go for a single 24" (1920*1200) display since 
they are absolutely great. I used to have two 19" screens and I get tell you 
that a single 24" screen works much much better. Also most EDA tools require 
large high-res screens, look at the number of windows in Modelsim or HDL 
designer, you simply can not use them on anything less than 1280*1024 unless 
you are one of those persons that can watch and enjoy a video on your mobile 
(cell phone) :-)

>
> The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various
> processors for significant money.  The first step-up is to a T5470 (1.6
> GHz) for $75 and others range up to $575!  I am thinking I can live
> with the slower processor.  The memory is 2GB.

Go for 4Gbyte, this will make your P&R run a lot faster. Yes you can only 
use 3.2GByte under XP but even the extra 1.2Gbyte will make a difference.

>
> I was looking at the Vostro 1000 earlier this week with an AMD TK-53
> processor (1.5 GHz, 512 KB cache) and a smaller hard drive.  It was
> $50 more so the 1500 looks like the better deal.  Are there any
> significant differences in the two CPUs for FPGA work?  I guess the
> small cache of the TK-53 would make it significantly slower for FPGA
> work.

According to an English PC magazine both Rock and PCnextday (zoostorm) came 
out as one of the fastest laptops in their price class:

http://www.rockdirect.com/
http://www.pcnextday.co.uk/

>
> I saw a thread from earlier this year discussing some of this.  I
> wonder how much laptops have improved since then.
>

With the current speed of development I would say a year is just about long 
enough before it is time to pass on your laptop to your kids or family 
member :-)

Hans
www.ht-lab.com



Article: 126226
Subject: Re: FPGA for hobby use
From: Andrew Burnside <andrew.burnside@sli-institute.ac.uk>
Date: Sat, 17 Nov 2007 03:38:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 14, 3:07 pm, cs_post...@hotmail.com wrote:
>
> The real problem is your insistence on using schematic entry for
> things of moderate complexity.
>
> Learn a hardware description language and your life will be much
> easier.

Whilst, I accept that it is necessary to know HDL, I think this is an
over-simplification of the issue.

There seems to be a complete aversion by digital hardware engineers to
graphical representation of problems, perhaps due to too many years of
limited schematic tools. There seems to be a 'Code Warrior' mentality
amongst many hardware engineers, that is reminds me of software
development a few years back. I have heard comments from my
colleagues, such as 'I look at the datasheet, and the code appears in
my head'. This is hardly a consistent process.

Considering the software case, generations of more complex languages
have meant that it is no longer necessary to code at a low level all
of the time. (Of course sometimes you need to). Graphical
representation such as UML means that you just draw your state
machines, rather than having to implement by hand. It is a lot easier
to review diagrams than code.

Now looking at hardware, whilst there may be a few occasions where it
is necessary to tweak state machines due to silicon cost /
performance, most of the time this is unecessary. Even if I am going
to write a state machine in HDL, I would much rather draw it out on
paper first, so that I can see if I have forgotten something. In
common usage, there are only so many maintainable ways to implement a
state machine, which means it is a sensible thing to template (or use
a graphical tool). For those who argue about tweaking the state
coding, this is only necessary in a few cases, as most of the time the
synthesis tool will probably change it anyhow. This is why I have now
moved to SystemVerilog enums for run of the mill state machines (much
less hassle, allowing me to concentrate on the bigger picture). Of
course, there are other instances e.g. RAM based state machines, where
you may want to do something different, but this is the exception
rather than the rule.

Having come originally from a DSP background, drawing out dataflow
diagrams of the progress of data makes sense during algorithm design.
e.g. it is much easier to have idea of multirate / CIC filters etc. by
drawing them out. Similarly, in my current non-DSP FPGA design by
drawing a block diagram of the data flow through FIFOs, compare
units,  memory interface etc., I had a better idea of what was
happening before I started to implement it. Whilst, detail may warrant
the use of HDL, it is much easier to understand how something works at
a macroscopic level by visualising it.

Another example, would be the design of clock domain crossing
schemes / handshaking etc. Personally, I find it much easier to draw
out a bunch of latches, associated timing diagram, or even a petri net
than leap straight in. That way there is no ambiguity about the
functionality that I want to implement, and I can trace the signals
round even before starting to write HDL.

I think someone mentioned about all FPGAs being LUT4. This is not
true, as Virtex-5s are LUT6. Implementation specific tweaks are always
going to be necessary for some apps, but are a complete waste of time
if you don't actually need them as they reduce the portability of your
code. I doubt that everyone is working on the hairy edge all of the
time.

Of course, synthesis all the way down from a specification level
description is not here. However, considered use of a combination of
graphical and text based approaches can make life a lot easier.




Article: 126227
Subject: how to KEEP_HIERARCHY [EDK]
From: Pasacco <pasacco@gmail.com>
Date: Sat, 17 Nov 2007 05:38:18 -0800 (PST)
Links: << >>  << T >>  << A >>
dear

In EDK 8.2, I am finding how to set up XST synthesis option
"KEEP_HIERARCHY = YES", with no luck.

Could someone tell me how to set "hierarchy" for synthesis step?

Thank you in advance

Article: 126228
Subject: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Sat, 17 Nov 2007 08:00:27 -0800 (PST)
Links: << >>  << T >>  << A >>
I looked at XAPP0058 which describes some algorithms for in system
programming of some Xilinx CPLDs.
 It appears that there are enough data to program a XPLA3 device once
I have the binary data I want to program without needing any more
tools/software/hoops_to_jump_through_I_havent_thought_of.
 However, given the long history of programming data secrecy (of
not just Xilinx, they only pioneered that, I believe) I would like to
get
a confirmation by someone who has done it that this is actually
possible for the XPLA3.
 Can I produce a binary using ABEL or whatever I can find in their
free software (the way this used to be possible using PHDL before
Xilinx bought and made the Coolrunner programming secret) and
program it into their xpla3 parts _without_ using any JTAG
tools/software other than those I make? Would I be able to utilize all
CPLD resources with their free software (as far as producing the
binary
is concerned, that is)?
 I am using my own JTAG hardware/software, it runs under DPS,
under which my logic compiler for the Philips coolrunner used to run
(still does, just no parts available). Adapting it to do anything is
not a problem, as long as "anything" is not kept secret.
 This may sound overly paranoid, but I do expect all sorts of catches
nowadays not only from Xilinx, hence my question.
 IIRC Xilinx had something in the agreement with Philips to support
all
previous customers, but I am not in the mood for legal battles, I just
need a usable CPLD (not one which comes with a PC/MS or whatever
attached to it in order to be written to) without having to do a lot
of
reverse engineering.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Article: 126229
Subject: Re: Block-ram FIFO in Xilinx
From: "zlotawy" <paraliczb@NO_SPAM_orange.pl>
Date: Sat, 17 Nov 2007 17:04:25 +0100
Links: << >>  << T >>  << A >>

Uzytkownik "Peter Alfke" <peter@xilinx.com> napisal w wiadomosci 
news:e137a2f3-69c2-429a-a660-6b824c41c9e7@b40g2000prf.googlegroups.com...
>I agree with Ray (as always).
> What is the data width and addressing depth of your synchronous FIFO?
> Peter Alfke, Xilinx
>




data width is 36 bits or 128.
Depth hmmmm .. I think about 100 words..

zlotawy 



Article: 126230
Subject: Re: Low cost FPGA w/serdes
From: austin <austin@xilinx.com>
Date: Sat, 17 Nov 2007 09:21:12 -0800
Links: << >>  << T >>  << A >>
Luc,

Contact your disti or FAE.

Austin

Article: 126231
Subject: Re: simulating xilinx block ram with modelsim
From: Duane Clark <junkmail@junkmail.com>
Date: Sat, 17 Nov 2007 17:26:00 GMT
Links: << >>  << T >>  << A >>
u_stadler@yahoo.de wrote:
> 
> thanks for the hint how to infer block ram. i will try that out!
> (why istn't it a good idea to use the core generator for simple block
> memory? just beauty reasons?)

Beauty is one good reason. Then there is the need to fire up coregen and 
and involve a bunch of Xilinx libraries, and get those all compiled 
correctly. And changing a parameter, like width or depth requires 
another run of coregen. And then there is the issue that the Xilinx 
simulation models for the BRAMs are very slow. The inferred method 
simulates much faster.

> i still would be curious though what's wrong the way i tried it?!? can
> you give me a hint there?

In your original posting, you said:
> but whatever i do to the ports of the memory they always stay 'x'.
> shouldn't at least the input port be '0' or '1' if i apply that
> signal?

Are you saying that WR and RD are always 'x'? If so, your problem is 
likely elsewhere, not with the BRAM model. That generally means you have 
two or more places where WR and RD are being driven, or nowhere where 
they are being driven.

Article: 126232
Subject: Re: VHDL language is out of date! Why? I will explain.
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 17 Nov 2007 10:23:09 -0800
Links: << >>  << T >>  << A >>
psihodelia@googlemail.com wrote:

> Conceptually VHDL is not bad at all, it supports a lot of things, well
> in theory. But in praxis ...

Here's my workaround using the thunderbird news reader:
1. Click on the OP's posting.
2. Message, Create Filter from Message, OK, Close.

   -- Mike Treseler

Article: 126233
Subject: Re: VHDL language is out of date! Why? I will explain.
From: Filip Miletic <filmil@gmTRIPail.com>
Date: Sat, 17 Nov 2007 20:07:00 +0100
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Here's my workaround using the thunderbird news reader:
> 1. Click on the OP's posting.
> 2. Message, Create Filter from Message, OK, Close.

Oh, that's how it is done!  *plonk*
To the rest: please don't feed the trolls.

f

Article: 126234
Subject: Re: VHDL language is out of date! Why? I will explain.
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sat, 17 Nov 2007 20:52:59 +0100
Links: << >>  << T >>  << A >>
HT-Lab wrote:
> <psihodelia@googlemail.com> wrote in message 
> news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com...
> 
>>Just look at its syntax. It is so archaic that anyone who had any deal
>>with Python will just laugh. Try, say, to create a simple VGA
>>controller, which is simply readable.
> 
> 
> Ok, in that case start writing your VGA controller in Python, then go to 
> http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an 
> FPGA prototype board and report back to us how incredible simple and quick 
> it was.... :-)

I hope some one will take the project :-) (You'll need a development
version for VHDL conversion.) Here's what to expect.

The synthesizable RTL subset is what it is. Conceptually, there's little
to be gained from using MyHDL or whatever instead of VHDL for this.
There are good and bad ways to do it, but it will all be fairly "low level".
I'm not sure the OP understands that. It's not a syntax issue.

Having said that, MyHDL RTL has interesting features. In particular,
it has a "hardware designer's dream type" (or at least my dream):
a constrainable integer type like in VHDL (but not restricted to
32 bits ...), with an indexing and slicing interface for bit access.
All issues with signed/unsigned, resizing, casting, std_logic_arith
versus numeric_std, ... simply go away. The integer-like MyHDL type
simply works as integers do, and the convertor takes care of all
those low-level issues.

I'm still puzzled why nobody had this idea before (and why I'm not
getting more praise :-)), but in any case, it's not a matter
of syntax. I put it in, and I could specify how to do it in any
other language.

If you like dynamic languages (not everybody does), you'll enjoy
using MyHDL/python especially during verification. There you can
use the full power of python, which is in my opinion invariably
useful. Combined with a unit test framework such as py.test,
verification almost becomes fun :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Article: 126235
Subject: Quartus II warning: "pass-through logic has been added"
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Sat, 17 Nov 2007 13:52:48 -0800 (PST)
Links: << >>  << T >>  << A >>
I tried asking this in the Altera forum, but to no avail.

The crux of my question is why the template that Quatus itself
suggests results in a warning and how to fix that?

For portability and readability I strongly prefer infering memory, but
I seem to be having a very hard time getting Quartus II 7.2 to behave
as expected. Quartus own template (pick edit -> insert template ->
single port ram. The code included below) when translated produces
this warning:

"Warning: Inferred RAM node "ram~0" from synchronous design logic.
Pass-through logic has been added to match the read-during-write
behavior of the original design."

Indeed, the template is pass-through, but that is be directly
supported by the M4K memory blocks in the context I'm using (no mixed
port sizes or clocks).

The setting "Add Pass-Through Logic to Inferred RAMs" defaults to
"On", but I don't understand that option. It seems to me that setting
it to "Off" would instruct Quartus II to infer logic that doesn't
implement exactly what the Verilog specifies and would certainly cause
a discrepancy when simulated with Icarus Verilog.


To make matters even more entertaining, the online help disagrees with
this template. Notably, the memory update is using a non-blocking
assignment

if (we) ram[addr] <= data

and that doesn't infer the pass-through logic.

Unfortunately, both infers Simple Dual RAM according to the Analysis &
Synthesis RAM Summary.

Is it even possible to infer Single Port RAM? (I care because I want
to pack two single port rams into one M4K block).

Help appreciated,
Tommy

.... code below ....

// Quartus II Verilog Template
// Single port RAM with single read/write address

module single_port_ram
(
input [(DATA_WIDTH-1):0] data,
input [(ADDR_WIDTH-1):0] addr,
input we, clk,
output reg [(DATA_WIDTH-1):0] q
);

parameter DATA_WIDTH = 8;
parameter ADDR_WIDTH = 6;

// Declare the RAM variable
reg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0];

always @ (posedge clk)
begin
// Write
if (we)
ram[addr] = data;

// Read returns NEW data at addr if we == 1'b1. This is the
// natural behavior of TriMatrix memory blocks in Single Port
// mode
q <= ram[addr];
end

endmodule

Article: 126236
Subject: Re: simulating xilinx block ram with modelsim
From: John Retta <jretta@rtc-inc.com>
Date: Sat, 17 Nov 2007 15:27:59 -0700
Links: << >>  << T >>  << A >>
[1] As others suggest, make sure that all
inputs are known ... not X.  X in results in
X out.

[2] The test bench should initialize memory
first, then read data, OR use the initialization
attributes of the BLKRAM to initialize values.
I would try the latter first, since if you are
relatively new to simulation, you can get the
READ working before the WRITE.

Take a look at your install directory
/xilinx/doc/usenglish/books/docs/lib.pdf
the section on RAMB for the syntax of initializing
the device contents in your respective language
(Verilog or VHDL).

[3] You may have to add delays to your nets for
some of your incoming signals relative to your
clk.  The unisim models perform timing checks, and
if you violate setup and hold (as you do for RTL
sims ... who cares ... we the sim model does),
the model outputs X.

[4] The suggestion to use inference of memories
is a good one.  For many years I instantiated
BLKRAMs .... my rationale was I synthesized exactly
what I wanted  ... this was based on earlier
experience of fighting tools to synthesize a
certain configuration of memory.  Anyway,
a friend let me know this was terribly inefficient
from a simulation point of view ... and I
disagreed.  So I coded up a testbench for
bench marking purposes of instantiated blkram
vs inferred memory, and the instantiated
blkram ran 5x slower.

Now if you were to pay your tool vendor for
a simulator with 5x performance improvement,
you might go bankrupt.

-- 

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

phone : 303.926.0068
email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

Article: 126237
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 18 Nov 2007 11:43:31 +1300
Links: << >>  << T >>  << A >>
Didi wrote:
> I looked at XAPP0058 which describes some algorithms for in system
> programming of some Xilinx CPLDs.
>  It appears that there are enough data to program a XPLA3 device once
> I have the binary data I want to program without needing any more
> tools/software/hoops_to_jump_through_I_havent_thought_of.
>  However, given the long history of programming data secrecy (of
> not just Xilinx, they only pioneered that, I believe) I would like to
> get
> a confirmation by someone who has done it that this is actually
> possible for the XPLA3.
>  Can I produce a binary using ABEL or whatever I can find in their
> free software (the way this used to be possible using PHDL before
> Xilinx bought and made the Coolrunner programming secret) and
> program it into their xpla3 parts _without_ using any JTAG
> tools/software other than those I make? Would I be able to utilize all
> CPLD resources with their free software (as far as producing the
> binary
> is concerned, that is)?
>  I am using my own JTAG hardware/software, it runs under DPS,
> under which my logic compiler for the Philips coolrunner used to run
> (still does, just no parts available). Adapting it to do anything is
> not a problem, as long as "anything" is not kept secret.
>  This may sound overly paranoid, but I do expect all sorts of catches
> nowadays not only from Xilinx, hence my question.
>  IIRC Xilinx had something in the agreement with Philips to support
> all
> previous customers, but I am not in the mood for legal battles, I just
> need a usable CPLD (not one which comes with a PC/MS or whatever
> attached to it in order to be written to) without having to do a lot
> of
> reverse engineering.
> 
> Dimiter

If you consider yourself the same as a programmer manufacturer :

My device programmer lists

PZ5032
PZ3032
XC3032XL
XC2C32A

so, that means the algorithms for all of those are published.

-jg



Article: 126238
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Sat, 17 Nov 2007 15:12:57 -0800 (PST)
Links: << >>  << T >>  << A >>
A few hours of digging later I found out that the JTAG
sequences needed to write to a XPLA3 and Coolrunner-II
are publically available.
 However, the JEDEC -> JTAGgable fuse address translation
map is not (I do have that for the Philips Coolrunner,
the bit locations in the JTAG sequence descriptions have
nothing to do with the bit locations in the JEDEC file).
 The suggested way is to go through a variety of hoops,
obviously for no other reason than to obscure the fact
that one has to pay them up to translate the bit locations
for me.
 Notice this fact is _very_ obscure, I am not sure
many - if any - people realise it, apparently done so
the user would discover that fact when it is too late
(after having designed the part in).

Do people know that? If I am more lucky, has anyone
found the solution to that? (paying up for being allowed
to program a part I have bought is not something I would
consider, this is racket rather than business in my book).

Thanks,

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 17, 6:00 pm, Didi <didi...@gmail.com> wrote:
> I looked at XAPP0058 which describes some algorithms for in system
> programming of some Xilinx CPLDs.
>  It appears that there are enough data to program a XPLA3 device once
> I have the binary data I want to program without needing any more
> tools/software/hoops_to_jump_through_I_havent_thought_of.
>  However, given the long history of programming data secrecy (of
> not just Xilinx, they only pioneered that, I believe) I would like to
> get
> a confirmation by someone who has done it that this is actually
> possible for the XPLA3.
>  Can I produce a binary using ABEL or whatever I can find in their
> free software (the way this used to be possible using PHDL before
> Xilinx bought and made the Coolrunner programming secret) and
> program it into their xpla3 parts _without_ using any JTAG
> tools/software other than those I make? Would I be able to utilize all
> CPLD resources with their free software (as far as producing the
> binary
> is concerned, that is)?
>  I am using my own JTAG hardware/software, it runs under DPS,
> under which my logic compiler for the Philips coolrunner used to run
> (still does, just no parts available). Adapting it to do anything is
> not a problem, as long as "anything" is not kept secret.
>  This may sound overly paranoid, but I do expect all sorts of catches
> nowadays not only from Xilinx, hence my question.
>  IIRC Xilinx had something in the agreement with Philips to support
> all
> previous customers, but I am not in the mood for legal battles, I just
> need a usable CPLD (not one which comes with a PC/MS or whatever
> attached to it in order to be written to) without having to do a lot
> of
> reverse engineering.
>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------


Article: 126239
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Sat, 17 Nov 2007 15:17:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Jim,

> My device programmer lists
>
> PZ5032
> PZ3032
> XC3032XL
> XC2C32A
>
> so, that means the algorithms for all of those are published.

do you mean there should be all data out there so one can write
what it takes to program a device from a JEDEC file? So far I
fail to find out how (all day), please send some more hint
(also please take my other posting about JEDEC <-> JTAG mapping into
account).

Dimiter

On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > I looked at XAPP0058 which describes some algorithms for in system
> > programming of some Xilinx CPLDs.
> >  It appears that there are enough data to program a XPLA3 device once
> > I have the binary data I want to program without needing any more
> > tools/software/hoops_to_jump_through_I_havent_thought_of.
> >  However, given the long history of programming data secrecy (of
> > not just Xilinx, they only pioneered that, I believe) I would like to
> > get
> > a confirmation by someone who has done it that this is actually
> > possible for the XPLA3.
> >  Can I produce a binary using ABEL or whatever I can find in their
> > free software (the way this used to be possible using PHDL before
> > Xilinx bought and made the Coolrunner programming secret) and
> > program it into their xpla3 parts _without_ using any JTAG
> > tools/software other than those I make? Would I be able to utilize all
> > CPLD resources with their free software (as far as producing the
> > binary
> > is concerned, that is)?
> >  I am using my own JTAG hardware/software, it runs under DPS,
> > under which my logic compiler for the Philips coolrunner used to run
> > (still does, just no parts available). Adapting it to do anything is
> > not a problem, as long as "anything" is not kept secret.
> >  This may sound overly paranoid, but I do expect all sorts of catches
> > nowadays not only from Xilinx, hence my question.
> >  IIRC Xilinx had something in the agreement with Philips to support
> > all
> > previous customers, but I am not in the mood for legal battles, I just
> > need a usable CPLD (not one which comes with a PC/MS or whatever
> > attached to it in order to be written to) without having to do a lot
> > of
> > reverse engineering.
>
> > Dimiter
>
> If you consider yourself the same as a programmer manufacturer :
>
> My device programmer lists
>
> PZ5032
> PZ3032
> XC3032XL
> XC2C32A
>
> so, that means the algorithms for all of those are published.
>
> -jg


Article: 126240
Subject: Re: Quartus II warning: "pass-through logic has been added"
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 17 Nov 2007 23:48:39 GMT
Links: << >>  << T >>  << A >>

"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message 
news:c657aada-8565-4ce8-a4c9-257914aff3b8@d21g2000prf.googlegroups.com...
>I tried asking this in the Altera forum, but to no avail.
>
> The crux of my question is why the template that Quatus itself
> suggests results in a warning and how to fix that?
>
If the design functions as you want it to and meets your performance 
requirements then what needs to be 'fixed'?  Not every warning needs to be 
addressed as a design change, many should really just be 'note', not 
'warning'.  The comments in the template generated code, seem to indicate 
that this is how they intend it to work.  If that is not exactly the 
function you want then don't use the template, code it to function how you 
need it to work.

KJ



Article: 126241
Subject: Re: Quartus II warning: "pass-through logic has been added"
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Sat, 17 Nov 2007 18:21:38 -0600
Links: << >>  << T >>  << A >>

>If the design functions as you want it to and meets your performance 
>requirements then what needs to be 'fixed'?  Not every warning needs to be 
>addressed as a design change, many should really just be 'note', not 
>'warning'.

The usual reason for getting rid of  warnings is so you don't have to
think about them next time.

Another reason is so that you don't miss an important one because
it's lost in the clutter.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 126242
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 18 Nov 2007 13:41:53 +1300
Links: << >>  << T >>  << A >>
Didi wrote:

> Hi Jim,
> 
> 
>>My device programmer lists
>>
>>PZ5032
>>PZ3032
>>XC3032XL
>>XC2C32A
>>
>>so, that means the algorithms for all of those are published.
> 
> 
> do you mean there should be all data out there so one can write
> what it takes to program a device from a JEDEC file? So far I
> fail to find out how (all day), please send some more hint
> (also please take my other posting about JEDEC <-> JTAG mapping into
> account).

  Basically, yes. Clearly our programemr supplier (ee tools) has done this.

  Mostly they use the JTAG pins and pathway, tho some PLDs also have 
extra means to jtag-unlock, which needs more pins.

  It means that progamming documents must exist, and be sent to the
programmer manufacturers.

  They may not be fully public, but they are not 'closed' either.

  So ask Xilinx for the info, explain you are manufacturing device 
programmers.

  If they prove too hard to work with, you could try Atmel etc
They have appx equivalent devices to the smaller XPLA3

  A working device programmer is also not a bad way to reality-check your
work.
  eg You can pgm a part, and then confirm you can read it in your system,
and then pgm in your system, and read/save the result, to analyse if
some bits are in the wrong place.

-jg



> 
> Dimiter
> 
> On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>Didi wrote:
>>
>>>I looked at XAPP0058 which describes some algorithms for in system
>>>programming of some Xilinx CPLDs.
>>> It appears that there are enough data to program a XPLA3 device once
>>>I have the binary data I want to program without needing any more
>>>tools/software/hoops_to_jump_through_I_havent_thought_of.
>>> However, given the long history of programming data secrecy (of
>>>not just Xilinx, they only pioneered that, I believe) I would like to
>>>get
>>>a confirmation by someone who has done it that this is actually
>>>possible for the XPLA3.
>>> Can I produce a binary using ABEL or whatever I can find in their
>>>free software (the way this used to be possible using PHDL before
>>>Xilinx bought and made the Coolrunner programming secret) and
>>>program it into their xpla3 parts _without_ using any JTAG
>>>tools/software other than those I make? Would I be able to utilize all
>>>CPLD resources with their free software (as far as producing the
>>>binary
>>>is concerned, that is)?
>>> I am using my own JTAG hardware/software, it runs under DPS,
>>>under which my logic compiler for the Philips coolrunner used to run
>>>(still does, just no parts available). Adapting it to do anything is
>>>not a problem, as long as "anything" is not kept secret.
>>> This may sound overly paranoid, but I do expect all sorts of catches
>>>nowadays not only from Xilinx, hence my question.
>>> IIRC Xilinx had something in the agreement with Philips to support
>>>all
>>>previous customers, but I am not in the mood for legal battles, I just
>>>need a usable CPLD (not one which comes with a PC/MS or whatever
>>>attached to it in order to be written to) without having to do a lot
>>>of
>>>reverse engineering.
>>
>>>Dimiter
>>
>>If you consider yourself the same as a programmer manufacturer :
>>
>>My device programmer lists
>>
>>PZ5032
>>PZ3032
>>XC3032XL
>>XC2C32A
>>
>>so, that means the algorithms for all of those are published.
>>
>>-jg
> 
> 


Article: 126243
Subject: Re: Quartus II warning: "pass-through logic has been added"
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 18 Nov 2007 02:12:24 GMT
Links: << >>  << T >>  << A >>

"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message 
news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net...
>
>>If the design functions as you want it to and meets your performance
>>requirements then what needs to be 'fixed'?  Not every warning needs to be
>>addressed as a design change, many should really just be 'note', not
>>'warning'.
>
> The usual reason for getting rid of  warnings is so you don't have to
> think about them next time.
>
> Another reason is so that you don't miss an important one because
> it's lost in the clutter.
>
Both of those are just 'motherhood and apple pie' statements though. 
Quartus will generate a 'warning' when it inserts a buffer to redrive a 
signal for whatever reason.  Do you change the design so that the buffer 
doesn't get inserted?  The answer there depends on performance.  If the 
design meets the timing requirements and has adequate margin then you're 
best off leaving the design as is (thereby leaving the warning).  In the 
OP's case of the RAM, he can probably change the function of the RAM to 
avoid use of the pass-thru mode and get rid of the warning, but if his 
design requires that mode of operation for whatever reason then he's broken 
the function of his design but gotten rid of the warning....bad tradeoff in 
my opinion.  Don't break function to get rid of warnings.

The nature of warnings should be understood.  If the warning is a symptom of 
a design issue then they should be fixed; if not they can be either left 
alone or possibly fixed so they don't cause clutter...as long as cleaning 
clutter does not compromise function or performance.

KJ 



Article: 126244
Subject: Re: Quartus II warning: "pass-through logic has been added"
From: rickman <gnuarm@gmail.com>
Date: Sat, 17 Nov 2007 19:52:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 17, 9:12 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Hal Murray" <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote in message
>
> news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net...
>
> >>If the design functions as you want it to and meets your performance
> >>requirements then what needs to be 'fixed'?  Not every warning needs to be
> >>addressed as a design change, many should really just be 'note', not
> >>'warning'.
>
> > The usual reason for getting rid of  warnings is so you don't have to
> > think about them next time.
>
> > Another reason is so that you don't miss an important one because
> > it's lost in the clutter.
>
> Both of those are just 'motherhood and apple pie' statements though.
> Quartus will generate a 'warning' when it inserts a buffer to redrive a
> signal for whatever reason.  Do you change the design so that the buffer
> doesn't get inserted?  The answer there depends on performance.  If the
> design meets the timing requirements and has adequate margin then you're
> best off leaving the design as is (thereby leaving the warning).  In the
> OP's case of the RAM, he can probably change the function of the RAM to
> avoid use of the pass-thru mode and get rid of the warning, but if his
> design requires that mode of operation for whatever reason then he's broken
> the function of his design but gotten rid of the warning....bad tradeoff in
> my opinion.  Don't break function to get rid of warnings.
>
> The nature of warnings should be understood.  If the warning is a symptom of
> a design issue then they should be fixed; if not they can be either left
> alone or possibly fixed so they don't cause clutter...as long as cleaning
> clutter does not compromise function or performance.

But aren't you making an assumption that "the design functions as you
want"?  The OP may not have complained that it did not simulate
correctly or that it did not meet performance.  However, he is clearly
concerned that it is not implementing as he requires.

"Is it even possible to infer Single Port RAM? (I care because I want
to pack two single port rams into one M4K block)."  This sounds like
it is not working as he wants it to.  But then I don't think he should
be using two single port rams.  If I understand what he is doing, he
may be asking the tool to be smarter than it is.  Perhaps he needs to
use a dual port ram and tie the high order address line high for one
port and low for the other.  Then the two ports should function as two
single port rams with half the number of words.

Article: 126245
Subject: Altera webpack for Linux?
From: radarman <jshamlet@gmail.com>
Date: Sat, 17 Nov 2007 20:58:37 -0800 (PST)
Links: << >>  << T >>  << A >>
I noticed that the Xilinx webpack version of ISE now runs in Linux. I
seem to recall in the past that the webpack was a Windows only tool,
so this seems like a signficant shift.

Does anyone know if Altera has any plans to release a Quartus webpack
for Linux? I still prefer Altera devices for my hobby work even though
my current employer is 100% Xilinx. However, I'm looking down the
barrel of Vista on my next system, and while I would prefer to migrate
to Linux, I can't justify buying a license for Quartus to play at
home.

I suppose the other alternative is to bite the bullet, put my Altera
dev boards away, and migrate to Xilinx dev boards.

Article: 126246
Subject: Re: Quartus II warning: "pass-through logic has been added"
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Sat, 17 Nov 2007 23:49:28 -0600
Links: << >>  << T >>  << A >>

>> The usual reason for getting rid of  warnings is so you don't have to
>> think about them next time.
>>
>> Another reason is so that you don't miss an important one because
>> it's lost in the clutter.
>>
>Both of those are just 'motherhood and apple pie' statements though.

I guess you go to a different church than I do.
 

>The nature of warnings should be understood.  If the warning is a symptom of 
>a design issue then they should be fixed; if not they can be either left 
>alone or possibly fixed so they don't cause clutter...as long as cleaning 
>clutter does not compromise function or performance.

I'd claim that if they can't be "fixed" without breaking the design,
then the tools are broken.  I'm happy to add something to the code
to tell the tools that I know about this case.

I want warnings when I might be doing something wrong or even slightly fishy.

Leaving them alone is not a sensible approach if there are more than a few.
The clutter gets in the way of finding important warnings.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 126247
Subject: Re: Quartus II warning: "pass-through logic has been added"
From: MikeShepherd564@btinternet.com
Date: Sun, 18 Nov 2007 09:55:05 +0000
Links: << >>  << T >>  << A >>
>Both of those are just 'motherhood and apple pie' statements...

What?

Article: 126248
Subject: synthesizing vqm with parameters with quartus 7.1sp1
From: hershkoy@gmail.com
Date: Sun, 18 Nov 2007 02:02:03 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I have a verilog module in my project, which is instantiated in the
design 3 times, each time with different parameters. I generated 3
different vqm files outside the Quartus project (with Synplify), one
for each instantiation. How can I tell Quartus which vqm file should
be linked to its appropriate block?

With regards,
Hezi

Article: 126249
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Sun, 18 Nov 2007 02:06:58 -0800 (PST)
Links: << >>  << T >>  << A >>
>   So ask Xilinx for the info, explain you are manufacturing device
> programmers.
>
>   If they prove too hard to work with, you could try Atmel etc
> They have appx equivalent devices to the smaller XPLA3

Well thanks, Jim, sounds encouraging. Have not wasted any time talking
programming data to their support for years, time to try again may be.
I strongly suspect I know what the result will be, though.

>   It means that progamming documents must exist, and be sent to the
> programmer manufacturers.

Are you saying you can program a Coolrunner using a non-Xilinx
programmer and a _JEDEC_ file? Without the programmer using
(or asking you to use) some paid Xilinx software to do some
fuse address mapping?
 Generally this is the question Xilinx' documents do not
answer (and seem to deliberately obscure).

>   A working device programmer is also not a bad way to reality-check your
> work.
>   eg You can pgm a part, and then confirm you can read it in your system,
> and then pgm in your system, and read/save the result, to analyse if
> some bits are in the wrong place.

Oh I do not need that, last time I did it for the original Coolrunner
it took me weeks rather than months to do the whole thing having
just the data and a few chips. It totally took me about 3 months
to write a suitable logic compiler (similar - not directly
compatible - to PHDL, but more flexible/powerful, with all the DPS
scripting. macros etc.) and some reverse engineering I had to do
because I did not have all the data (Philips were easier to deal
with than Xilinx - I guess everyone is that - but sent me only
_most_ of the data, omitted a significant part of them...).
 Programming a device via JTAG is a lot easier than they make
it sound (and cash in for), one just needs the device documentation.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


On Nov 18, 2:41 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > Hi Jim,
>
> >>My device programmer lists
>
> >>PZ5032
> >>PZ3032
> >>XC3032XL
> >>XC2C32A
>
> >>so, that means the algorithms for all of those are published.
>
> > do you mean there should be all data out there so one can write
> > what it takes to program a device from a JEDEC file? So far I
> > fail to find out how (all day), please send some more hint
> > (also please take my other posting about JEDEC <-> JTAG mapping into
> > account).
>
>   Basically, yes. Clearly our programemr supplier (ee tools) has done this.
>
>   Mostly they use the JTAG pins and pathway, tho some PLDs also have
> extra means to jtag-unlock, which needs more pins.
>
>   It means that progamming documents must exist, and be sent to the
> programmer manufacturers.
>
>   They may not be fully public, but they are not 'closed' either.
>
>   So ask Xilinx for the info, explain you are manufacturing device
> programmers.
>
>   If they prove too hard to work with, you could try Atmel etc
> They have appx equivalent devices to the smaller XPLA3
>
>   A working device programmer is also not a bad way to reality-check your
> work.
>   eg You can pgm a part, and then confirm you can read it in your system,
> and then pgm in your system, and read/save the result, to analyse if
> some bits are in the wrong place.
>
> -jg
>
>
>
> > Dimiter
>
> > On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>Didi wrote:
>
> >>>I looked at XAPP0058 which describes some algorithms for in system
> >>>programming of some Xilinx CPLDs.
> >>> It appears that there are enough data to program a XPLA3 device once
> >>>I have the binary data I want to program without needing any more
> >>>tools/software/hoops_to_jump_through_I_havent_thought_of.
> >>> However, given the long history of programming data secrecy (of
> >>>not just Xilinx, they only pioneered that, I believe) I would like to
> >>>get
> >>>a confirmation by someone who has done it that this is actually
> >>>possible for the XPLA3.
> >>> Can I produce a binary using ABEL or whatever I can find in their
> >>>free software (the way this used to be possible using PHDL before
> >>>Xilinx bought and made the Coolrunner programming secret) and
> >>>program it into their xpla3 parts _without_ using any JTAG
> >>>tools/software other than those I make? Would I be able to utilize all
> >>>CPLD resources with their free software (as far as producing the
> >>>binary
> >>>is concerned, that is)?
> >>> I am using my own JTAG hardware/software, it runs under DPS,
> >>>under which my logic compiler for the Philips coolrunner used to run
> >>>(still does, just no parts available). Adapting it to do anything is
> >>>not a problem, as long as "anything" is not kept secret.
> >>> This may sound overly paranoid, but I do expect all sorts of catches
> >>>nowadays not only from Xilinx, hence my question.
> >>> IIRC Xilinx had something in the agreement with Philips to support
> >>>all
> >>>previous customers, but I am not in the mood for legal battles, I just
> >>>need a usable CPLD (not one which comes with a PC/MS or whatever
> >>>attached to it in order to be written to) without having to do a lot
> >>>of
> >>>reverse engineering.
>
> >>>Dimiter
>
> >>If you consider yourself the same as a programmer manufacturer :
>
> >>My device programmer lists
>
> >>PZ5032
> >>PZ3032
> >>XC3032XL
> >>XC2C32A
>
> >>so, that means the algorithms for all of those are published.
>
> >>-jg




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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