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 108200

Article: 108200
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 10:14:57 -0700
Links: << >>  << T >>  << A >>
cblsrv emulates a Par III cable, so Impact doesn't have any idea,
cblsrv would use a Platform USB cable. One working firmware would be
good enough (unless they change the cableserver protocoll when using
Par III)

The windows debugging part is fairly easy, no breakpoints, or anything
nasty, just simply put API trace logs with dumping incoming/outgoing
data.

I'd be more interested to reverse engineer the Platform USB than Par
IV, because most new laptops and some desktops lack par ports anyway.

Reverse engineer the Digilent USB JTAG cable took roughly 2 days to
reverse engineer the basic protocol, but maybe the Platform USB is much
nastier.

Zoltan

Antti wrote:
> zcsizmadia@gmail.com schrieb:
>
> > Probably I miss something here.
> >
> > Why not just hook LPT or Jungo driver in windows, and see what is sent
> > to the cable? Or it is downloading the firmware at the very beginning
> > and it's a copyright issue to include the original firmware in your
> > open-source application?
> > The same way using a USB sniffer the communication can be reverse
> > engineered (unless the data is not crypted)
> >
> > Do you have any  Par IV or Platform USB cable I could borrow to see if
> > it could be reverse engineered?
> >
> > Zoltan
> >
> Zoltan,
>
> snooping the USB cable does not make much sense as it is always
> downloading the actual firmware, those any new release of ISE may have
> different firmware and completly new USB protocol. It could of course
> be possible to write an emulator for the USB chip and use the actual
> firmware, by emulating it in fake driver, but that is all too
> time consuming.
>
> now as of Cable IV, well I havent done windows kernel debugging for
> ages. I used todo it. But as of today I dont have debug tools that can
> put breakpoints on io access in running winXP system. Sure it can be
> done when windows is installed in qemu, etc, but its all
> pretty much pain.
>
> Or another way is to reverse engineer some xilinx DLL, what defenetly
> violates the licensing, and is boring anyway.
>
> So third option is to look at the jedec readback from Cable IV, sure
> after conversion to VHDL.
> 
> Antti


Article: 108201
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "Antti" <Antti.Lukats@xilant.com>
Date: 6 Sep 2006 10:20:43 -0700
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com schrieb:

> cblsrv emulates a Par III cable, so Impact doesn't have any idea,
> cblsrv would use a Platform USB cable. One working firmware would be
> good enough (unless they change the cableserver protocoll when using
> Par III)
>
> The windows debugging part is fairly easy, no breakpoints, or anything
> nasty, just simply put API trace logs with dumping incoming/outgoing
> data.
>
> I'd be more interested to reverse engineer the Platform USB than Par
> IV, because most new laptops and some desktops lack par ports anyway.
>
> Reverse engineer the Digilent USB JTAG cable took roughly 2 days to
> reverse engineer the basic protocol, but maybe the Platform USB is much
> nastier.
>
> Zoltan
>

ah? I am gettin old or what?
you can put "API trace logs" read write to physical IO?
to reverse the Cable IV that is required.

as of platform USB cable, it makes sens to use the natice cableserver
as gateway, so you are not troubled with the USB protocol or firmware
revision, etc

Antti


Article: 108202
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 10:21:04 -0700
Links: << >>  << T >>  << A >>
Uwe,

Did you have a chance to try my patch?

> Well, you probably don't need PPEXCL. The man page says:
I had the impression if you write CONTROL you need it. DLC5 doesn't
writes CONTROL, but Altera ByteBlaster does.
In my vmware environment I removed PPEXCL and it works for me (of
course with the patch)

> ioctl(...) !=0
I've already fixed them. Next week  probably I'll finish the Digilent
USB JTAG cable support in cblsrv, and will make a  new release with the
patches.

Zoltan

Uwe Bonnes wrote:
> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > On Linux the only test I did was using VmWare with direct I/O access
> > (actually ppdev didn't work for me, it said PPEXCL  failed).
>
> Well, you probably don't need PPEXCL. The man page says:
>
> "Most device drivers don't need exclusive access to the port. It's only
> provided in case it is really needed, for example for devices where access
> to the port is required for extensive periods of time (many seconds)."
>
> And testing for failure for an ioctl is better done like
> ioctl(...) !=0
>
> > Did you try to use with DIRECT_IO?
>
> Running cblsrv as root (and having windrvr6 still loaded) worked. However
> after unloading the windrvr6 module, I couldn't get things to work.
>
> > There is a cablehost directory under src. You can patch that to connect
> > to server and send some messages. I've used it to connet tit to the
> > Xilinx CableServer and figure out what the different write modes meant
>
> cablehost is for win32...
>
> > PS:
> > This weeken I'll try to more Linux testing.
>
> Fine
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 108203
Subject: Re: Global constants definition problem
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 6 Sep 2006 10:27:30 -0700
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
> Weng Tianxiang wrote:
>
> > I even deleted all work directory contents, recompile every modules,
> > but constants in the global package still don't change.
>
> Maybe they are declared in more than one place.
>
>         -- Mike Treseler

Hi MIke,
Never!

I tried to move all constant definitions from package entity module to
package body module, all constants usage are errors.

Weng


Article: 108204
Subject: Re: Global constants definition problem
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 6 Sep 2006 10:33:58 -0700
Links: << >>  << T >>  << A >>

Weng Tianxiang wrote:
> Mike Treseler wrote:
> > Weng Tianxiang wrote:
> >
> > > I even deleted all work directory contents, recompile every modules,
> > > but constants in the global package still don't change.
> >
> > Maybe they are declared in more than one place.
> >
> >         -- Mike Treseler
>
> Hi MIke,
> Never!
>
> I tried to move all constant definitions from package entity module to
> package body module, all constants usage are errors.
>
> Weng

Hi,
Is it possible that the error happens because I have used 2 levels of
constants:

constant DATA_BITS : integer := 16; <-- I change this value,
constant DATABITS  : integer := DATA_BITS; <-- this value doesn't
change

Weng


Article: 108205
Subject: Re: How to bound a Cores generated output in Modelsim
From: "alterauser" <fpgaengineerfrankfurt@arcor.de>
Date: 6 Sep 2006 10:39:33 -0700
Links: << >>  << T >>  << A >>
Well, I think this is your simulation bench (or the working toplevel,
no matter).

To work properly, Modelsim needs all the mentioned vhdl-files.
Typically you will create a project, add all the required files, and do
a recompile on the particular file, once you edited it.

Perhaps you choose "compile" manually in Modelsim and click on the
tenth.hdl. Maybe it does not compile due to an error ...


Article: 108206
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 6 Sep 2006 17:41:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> Uwe,

> Did you have a chance to try my patch?

The patches seem right, but the whole thing doesn't work when the windrvr6
module is unloaded. 

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

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

Article: 108207
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 10:45:10 -0700
Links: << >>  << T >>  << A >>
I've tested Impact without windriver and was working. Unfortunately I
have no access to Impact running on Linux :(

Zoltan

Uwe Bonnes wrote:
> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > Uwe,
>
> > Did you have a chance to try my patch?
>
> The patches seem right, but the whole thing doesn't work when the windrvr6
> module is unloaded.
>
> Bye
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 108208
Subject: Re: NON-CLK pins failed to route using a CLK template
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 06 Sep 2006 17:58:49 GMT
Links: << >>  << T >>  << A >>
dhruvakshad@gmail.com wrote:

>I am designing a frame grabber .The frame input is expeted at a very
>slow rate of 10mbps. I have 4 state machine strutures running at plb
>clock rate of 80mhz. I am not able to synchronize the capture of the
>packets properly. I am using a triemac ip from xilinx. The triemac
>works fine and does take in all the packets. However I get problem in
>the state machine part. The out put of state machines doesnt give
>proper results. When I run xps I get following warnings :
>
>1) wwww may have excessive skew because 73 NON-CLK pins failed to route
>using a CLK template
>
>2) xxxx may have excessive skew because    3 CLK pins failed to route
>using a CLK template.
>
>3) yyyy may have   excessive skew because   10 CLK pins and 6 NON_CLK
>pins failed to route using a CLK template.

These are bogus messages (see www.xilinx.com)

>wwww is a 2.5mhz clock signal( triemac )  dervied from 25mhz onboard
>clock by using a simple counter.This is the rate at which input is
>coming in.
>The signals xxxx and yyyy  are asynchronous signals which are gating
>the state machines.These signals are running at far lower rate .
>Should I use bufg or FDDRs to route these signals to statemachines ?

No, you should use flipflops (FD) to get these signals into the same
clock domain as the statemachine. Any asynchronous signal must be
buffered by 1 and only 1 flipflop to get your circuit to work
reliably.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108209
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 11:01:02 -0700
Links: << >>  << T >>  << A >>
>>you can put "API trace logs" read write to physical IO?

If they are using the HAL.DLL functions READ_PORT_UCHAR,
WRITE_PORT_UCHAR (or WRITE_PORT_xxx, READ_PORT_xxx). This is suggested
by MS instead of using in/out directly.

I've checked xpc4drvr.sys. It's using READ_PORT_UCHAR and
WRITE_PORT_UCHAR.
This should be fairly simple.

Unfortunately windriver6 implemented all of these functions (I guess
because of Linux). I've opened it a disassembler, and they have a bunch
of small wrapper functions to read/write I/O. Those functions can be
hooked, but it would be nasty.

Zoltan

Antti wrote:
> zcsizmadia@gmail.com schrieb:
>
> > cblsrv emulates a Par III cable, so Impact doesn't have any idea,
> > cblsrv would use a Platform USB cable. One working firmware would be
> > good enough (unless they change the cableserver protocoll when using
> > Par III)
> >
> > The windows debugging part is fairly easy, no breakpoints, or anything
> > nasty, just simply put API trace logs with dumping incoming/outgoing
> > data.
> >
> > I'd be more interested to reverse engineer the Platform USB than Par
> > IV, because most new laptops and some desktops lack par ports anyway.
> >
> > Reverse engineer the Digilent USB JTAG cable took roughly 2 days to
> > reverse engineer the basic protocol, but maybe the Platform USB is much
> > nastier.
> >
> > Zoltan
> >
>
> ah? I am gettin old or what?
> you can put "API trace logs" read write to physical IO?
> to reverse the Cable IV that is required.
>
> as of platform USB cable, it makes sens to use the natice cableserver
> as gateway, so you are not troubled with the USB protocol or firmware
> revision, etc
> 
> Antti


Article: 108210
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: cs_posting@hotmail.com
Date: 6 Sep 2006 11:13:25 -0700
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com wrote:
>
> Reverse engineer the Digilent USB JTAG cable took roughly 2 days to
> reverse engineer the basic protocol, but maybe the Platform USB is much
> nastier.

Given how inexpensive the digilent USB cable is, seems like it would
make sense to get that working and just forget about the xilinx usb
cable?


Article: 108211
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: cs_posting@hotmail.com
Date: 6 Sep 2006 11:16:30 -0700
Links: << >>  << T >>  << A >>
Andreas Ehliar wrote:
> On 2006-09-06, Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
> > "The standalone Xilinx Platform Cable USB is unsupported and untested. Since
> > its hardware is presumably very similar, it may be usable as-is or with some
> > minor hacking. "
>
> I have tested it and it doesn't work. One problem is that the CPLD on the
> platform cable does not get a supply voltage at all if the xup firmware is
> downloaded to the FX2 chip.

That sounds as much like an invitation to a solution as a problem...
the FX2 chip has decent documentation, right?  And you can figure out
which pin should be supplying the CPLD... so change the firmware to be
downloaded accordingly.  And then go after the data signals if it still
doesn't work.


Article: 108212
Subject: Re: Forth-CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 07 Sep 2006 07:43:05 +1200
Links: << >>  << T >>  << A >>
J Thomas wrote:
> rickman wrote:
> 
> 
>>Yes, there are few advantages to a Gray code counter.  But one is a
>>lower power consumption because only one bit changes on each increment.
>> Again this is unlikely to be noticed in a real chip given the small
>>size of the counter.
> 
> 
> If you're getting your code from offchip, and you need a new address
> every time you get a new instruction, then the power consumption
> advantage might add up, right?
> 
> To my way of thinking this is a braindead way to get code to a
> processor, but it seems to be standard.

  Generating a new address each time is certainly widespread, but there
are small pockets where this is done better.
  Some game machines have a smarter ALE + Counter scheme, and some
flash devices have Multi Cycle ALE +Clock schemes ( and
Serial flash memories all generates an address, and then streams the data )
  There are sync memories that have limited page-burst sizes, but they
are complex to use efficently.
-jg





Article: 108213
Subject: Re: Please help me with (insert task here)
From: mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene)
Date: Wed, 6 Sep 2006 11:51:25 PST
Links: << >>  << T >>  << A >>
"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> writes:
> "Jim Stewart" <jstewart@jkmicro.com> wrote

> > An SCR, placed across the terminals of a decent
> > sized gelcell will give a very rewarding blue
> > flash followed by an orange fireball after it's
> > been turned on.
> 
> We used to put those 0.5mm pencil fillings across the 220V terminals (the
> screw type that also accepts banana plugs) at the test benches at school....
> Especially the softer types (4-6B) produced a nice soft orange flash
> followed by enormous amounts of smoke :-)

Tantalum caps connected with reverse polarity will make
a good-sized bang when the encapsulation material
bounces off a hard object and/or will have a small
mushroom-shaped cloud rise from it.

If you happened to be looking at the moment when power
was applied to the old UV-erasable PROMs place in a
socket backward would put on an interesting show of
little pinpricks of light appearing at random spots
on the die.

Article: 108214
Subject: Re: Performance Appraisals
From: Charlie Edmondson <edmondson@ieee.org>
Date: Wed, 06 Sep 2006 12:57:42 -0700
Links: << >>  << T >>  << A >>
Michael A. Terrell wrote:
> 
> 
> 
>    Ernie wasn't very happy by the time it was over, then was forced to
> quit or be fired a few months later at a time when my word could have
> let him keep his job.  On top of that, I got ten times what he did for
> my Christmas bonus that year.  I made almost twice what he got that
> year, then he was looking for another job with the company telling his
> prospective new employers that they couldn't comment till the lawsuit
> was settled.  :)
> 
> 
> 
> 
Had a similiar situation when I worked on the 91 Express lanes toll 
road.  My boss was a real A-hole, who would do things like, pull out a 
knife and shave his arms, commenting on how sharp it was, while asking 
for the status of your assignments.  The threat was very thinly veiled...

Then, about 9 months later, I was working for the other toll road 
company and he came in for an interview.  For some reason, he wasn't 
hired... 8-)

Charlie

Article: 108215
Subject: Re: Forth-CPU design
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 06 Sep 2006 22:13:21 +0200
Links: << >>  << T >>  << A >>
rickman schrieb:

> Yes, there are few advantages to a Gray code counter.  But one is a
> lower power consumption because only one bit changes on each increment.

Whereas a binary counter changes two bits on average.
(1 + 1/2 + 1/4 + ....)
This saves you what, 5fW? And that is probably more than offset by more
switching internal signals in an FPGA implementation.

Kolja Sulimma

Article: 108216
Subject: Re: Forth-CPU design
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 06 Sep 2006 22:14:40 +0200
Links: << >>  << T >>  << A >>
rickman schrieb:
> J Thomas wrote:
>  At
> that size the power difference would be virtually unmeasureable.  

Ripple carry counter power is independant of counter size.
(Except for clock tree power)

Kolja

Article: 108217
Subject: Re: Please help me with (insert task here)
From: Jim Stewart <jstewart@jkmicro.com>
Date: Wed, 06 Sep 2006 13:51:22 -0700
Links: << >>  << T >>  << A >>
Everett M. Greene wrote:
> "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> writes:
> 
>>"Jim Stewart" <jstewart@jkmicro.com> wrote
> 
> 
>>>An SCR, placed across the terminals of a decent
>>>sized gelcell will give a very rewarding blue
>>>flash followed by an orange fireball after it's
>>>been turned on.
>>
>>We used to put those 0.5mm pencil fillings across the 220V terminals (the
>>screw type that also accepts banana plugs) at the test benches at school....
>>Especially the softer types (4-6B) produced a nice soft orange flash
>>followed by enormous amounts of smoke :-)
> 
> 
> Tantalum caps connected with reverse polarity will make
> a good-sized bang when the encapsulation material
> bounces off a hard object and/or will have a small
> mushroom-shaped cloud rise from it.
> 
> If you happened to be looking at the moment when power
> was applied to the old UV-erasable PROMs place in a
> socket backward would put on an interesting show of
> little pinpricks of light appearing at random spots
> on the die.

I remember that.  We called it the "You put the
chip in the socket backwards lamp".

BTW, the SCR trick works best with parts in a
TO-220 package.

Article: 108218
Subject: How to save preferences of modelsim
From: "fl" <rxjwg98@gmail.com>
Date: 6 Sep 2006 14:09:15 -0700
Links: << >>  << T >>  << A >>
Hi,
The default font of the source window in Modelsim III 6.1e is too
large. Although it is changed after I set it in "Tools-Edit
Preferences", it goes back the default value the next time I open
Modelsim. How can I avoid this? Thank you very much.


Article: 108219
Subject: Re: fastest FPGA
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2006 17:37:26 -0400
Links: << >>  << T >>  << A >>
rickman wrote:

> I guess it has been too long since I have used the SRL.  I had
> forgotten that the read port was addressable, but that only makes
> sense.  For a fixed delay shift register these inputs are just hard
> connected which is the way I have always used the SRLs.
> 
> I have not used them in many years.  I guess they are mostly useful for
> signal processing which I don't seem to do much anymore.  Otherwise I
> don't have many apps where delays are a good thing.
> 

The SRL16's are actually one of the most versatile blocks on the FPGA. 
You can use them for:

reprogrammable LUTs  --poor man's reconfiguration
dual port memory     --serial write port, parallel read
synchronous FIFO     --smallest FIFO implementation
data reordering	     --this is really cool for sorting and other apps
counters	
state machines
variable delays
fixed delays

The only one of these that is inferred by synthesis tools is the fixed 
delay, and that is also the least interesting out of all these.  I've 
probably used them for other things as well, but these are the ones that 
pop out at me.  It is a shame that Xilinx doesn't promote the usefulness 
of the SRL16 more than they do, as I suspect most users don't have a 
clue how powerful these little buggers are.

Article: 108220
Subject: Re: Qestion about the ability of synthesis
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2006 17:43:41 -0400
Links: << >>  << T >>  << A >>
radarman wrote:

> Thomas Stanka wrote:
> 
>>Torsten Alt schrieb:
>>
>>>Another thing is that i would try to avoid to compare values with
>>>"greater " or "lower" than a value. This can increase your logic since
>>>the synthesizer has to synthesize all this cases. In your case i would
>>
>>I disagree. Using '=' for counters may decrease your logic but may also
>>increase your logic[1]. But it will always be a pitfall, if your
>>counter value gets over (for inc-counter, else under)) the value your
>>looking for, due to any reason.
>>I just had to remove a bug from a co-designer basing on this pitfall.
>>
>>For a simple counter there are only external reasons like SEU that will
>>lead to this pitfall, in complex designs, there might be a erroneous
>>written if-then-else path leading to the situation were your counter
>>waits forever.
>>
>>bye Thomas
>>
>>[1] A 8 bit '=' needs 15 XOR2. A 8 bit '> 127'  is free in terms of
>>gates.
> 
> 
> Having seen almost every error one can make with counters, I prefer
> free-running counters with reload logic. This implies that the counter
> can never get "stuck". If, for some reason, the counter manages to
> enter an illegal state, it will self-correct. This usually implies that
> at least a small period will be garbage, but the system won't fail.
> 
> Also, while it sometimes it does make sense to make a counter 1 bit
> wider than the actual count, and use the MSB as a reload signal, you
> have to be careful. If you exceed the maximum length of a carry chain,
> the P&R tools will break the counter up, and you may lose more
> performance than if you had made the counter the exact width.
> 
> Of course, with most of my designs the reload value is never a power of
> 2, or the counter is under software control, so I typically write them
> the "normal" way anyway.
> 

You've got to make a pretty big counter before synthesis breaks it up.

The MSB to reload trick actually works quite well, even for 
non-power-of-2 and programmable counters.  The trick is to load the 
counter with the complement of the count (or load it with the count and 
decrement).  It is nice because it provides a direct decode of the 
terminal count and can be accomplished in one layer of logic if the load 
value is computed correctly.

Article: 108221
Subject: Re: Please help me with (insert task here)
From: "phaeton" <blahbleh666@hotmail.com>
Date: 6 Sep 2006 14:47:02 -0700
Links: << >>  << T >>  << A >>
Hi can someone please explain to me how to post to usenet?


Article: 108222
Subject: Xilinx Spartan 3 Configuration
From: "yy" <yy7d6@yahoo.com.ph>
Date: 6 Sep 2006 14:48:40 -0700
Links: << >>  << T >>  << A >>
Hi i have 3 X Spartan 3 to configure i followed the Master Serial
configuration from the application note, but the sample only has 2
device to configure (i.e. Master FPGA and Slave FPGA); and the M0-M2
pins for the Master are connected to GND and to 2.5V with Slave. If i
have 3 fpga to configure i have only one PROM, i will have a PROM,
MASTER, SLAVE1, SLAVE2. etc. chain will the M0-M2 pins tied to 2.5 for
all Slave FPGA?  How about the JTAG for configuring the PROM? How about
the Pull-Ups?

Thanks.


Article: 108223
Subject: Re: Please help me with (insert task here)
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Wed, 06 Sep 2006 21:51:19 GMT
Links: << >>  << T >>  << A >>

"phaeton" <blahbleh666@hotmail.com> wrote in message 
news:1157579221.974696.109440@e3g2000cwe.googlegroups.com...

> Hi can someone please explain to me how to post to usenet?

Use extra postage.




Article: 108224
Subject: Re: Please help me with (insert task here)
From: Jim Stewart <jstewart@jkmicro.com>
Date: Wed, 06 Sep 2006 14:56:08 -0700
Links: << >>  << T >>  << A >>
phaeton wrote:

> Hi can someone please explain to me how to post to usenet?

Um, you just did...




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