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 105475

Article: 105475
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: "EEngineer" <maricic@gmail.com>
Date: 24 Jul 2006 09:38:43 -0700
Links: << >>  << T >>  << A >>
I am using

Release Version: 8.1i
Application Version: I.24

I always get 1674KB ACE file, maybe that points to some problem?

Ed McGettigan wrote:
> EEngineer wrote:
> > What is the ACE file size that you created? All the demos are 1686KB
> > and the new ACE created with iMPACT is 1674KB.
>
> The file that I generated was 1686KB using the 8.1.03i (Service Pack 3)
> software. You can find out which version you are using the "Help -> About"
> menu.
> 
> Ed


Article: 105476
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: "EEngineer" <maricic@gmail.com>
Date: 24 Jul 2006 09:40:17 -0700
Links: << >>  << T >>  << A >>
 I use:

Service Pack 1


Ed McGettigan wrote:
> EEngineer wrote:
> > What is the ACE file size that you created? All the demos are 1686KB
> > and the new ACE created with iMPACT is 1674KB.
>
> The file that I generated was 1686KB using the 8.1.03i (Service Pack 3)
> software. You can find out which version you are using the "Help -> About"
> menu.
> 
> Ed


Article: 105477
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: "EEngineer" <maricic@gmail.com>
Date: 24 Jul 2006 09:56:02 -0700
Links: << >>  << T >>  << A >>
Summary of Bitgen Options:
+----------------------+----------------------+
| Option Name          | Current Setting      |
+----------------------+----------------------+
| Compress             | (Not Specified)*     |
+----------------------+----------------------+
| Readback             | (Not Specified)*     |
+----------------------+----------------------+
| CRC                  | Enable**             |
+----------------------+----------------------+
| DebugBitstream       | No**                 |
+----------------------+----------------------+
| ConfigRate           | 4**                  |
+----------------------+----------------------+
| StartupClk           | JtagClk              |
+----------------------+----------------------+
| CclkPin              | Pullup**             |
+----------------------+----------------------+
| DonePin              | Pullup**             |
+----------------------+----------------------+
| HswapenPin           | Pullup*              |
+----------------------+----------------------+
| M0Pin                | Pullup**             |
+----------------------+----------------------+
| M1Pin                | Pullup**             |
+----------------------+----------------------+
| M2Pin                | Pullup**             |
+----------------------+----------------------+
| PowerdownPin         | Pullup*              |
+----------------------+----------------------+
| ProgPin              | Pullup**             |
+----------------------+----------------------+
| InitPin              | Pullup**             |
+----------------------+----------------------+
| CsPin                | Pullup**             |
+----------------------+----------------------+
| DinPin               | Pullup**             |
+----------------------+----------------------+
| BusyPin              | Pullup**             |
+----------------------+----------------------+
| RdWrPin              | Pullup**             |
+----------------------+----------------------+
| TckPin               | Pullup**             |
+----------------------+----------------------+
| TdiPin               | Pullup**             |
+----------------------+----------------------+
| TdoPin               | Pullup**             |
+----------------------+----------------------+
| TmsPin               | Pullup**             |
+----------------------+----------------------+
| UnusedPin            | Pulldown**           |
+----------------------+----------------------+
| GWE_cycle            | 6**                  |
+----------------------+----------------------+
| GTS_cycle            | 5**                  |
+----------------------+----------------------+
| LCK_cycle            | NoWait**             |
+----------------------+----------------------+
| Match_cycle          | Auto*                |
+----------------------+----------------------+
| DONE_cycle           | 4**                  |
+----------------------+----------------------+
| Persist              | No*                  |
+----------------------+----------------------+
| DriveDone            | No**                 |
+----------------------+----------------------+
| DonePipe             | No**                 |
+----------------------+----------------------+
| Security             | None**               |
+----------------------+----------------------+
| UserID               | 0xFFFFFFFF**         |
+----------------------+----------------------+
| ActivateGclk         | No*                  |
+----------------------+----------------------+
| ActiveReconfig       | No*                  |
+----------------------+----------------------+
| PartialMask0         | (Not Specified)*     |
+----------------------+----------------------+
| PartialMask1         | (Not Specified)*     |
+----------------------+----------------------+
| PartialMask2         | (Not Specified)*     |
+----------------------+----------------------+
| PartialGclk          | (Not Specified)*     |
+----------------------+----------------------+
| PartialLeft          | (Not Specified)*     |
+----------------------+----------------------+
| PartialRight         | (Not Specified)*     |
+----------------------+----------------------+
| Encrypt              | No**                 |
+----------------------+----------------------+
| Key0                 | pick*                |
+----------------------+----------------------+
| KeyFile              | (Not Specified)*     |
+----------------------+----------------------+
| StartCBC             | pick*                |
+----------------------+----------------------+
| DCIUpdateMode        | AsRequired**         |
+----------------------+----------------------+
| ICAP_Select          | Auto*                |
+----------------------+----------------------+
| IEEE1532             | No*                  |
+----------------------+----------------------+
| Binary               | Yes                  |
+----------------------+----------------------+
 *  Default setting.
 ** The specified setting matches the default setting.

Running DRC.
DRC detected 0 errors and 0 warnings.
Creating bit map...
Saving bit stream in "test.bit".
Saving bit stream in "test.bin".
Bitstream generation is complete.


Article: 105478
Subject: Re: Hardware book like "Code Complete"?
From: "Andy" <jonesandy@comcast.net>
Date: 24 Jul 2006 10:03:17 -0700
Links: << >>  << T >>  << A >>
With variables, you don't have to wait an extra clock in single process
descriptions.

Andy


radarman wrote:
> KJ wrote:
> > "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message
> > news:1153510009.206861.78040@p79g2000cwp.googlegroups.com...
> > > Andy wrote:
> > >> Too bad the author is a proponent of the ancient style of separate
> > >> clocked and combinatorial processes in VHDL. He even uses a third
> > >> process for registered outputs.
> > >>
> > >> I think he needs to discover what variables can do for you in a clocked
> > >> process.
> > >
> > > Really?  Which of his arguments do you disagree with?
> > >
> > > I always thought of the two-process style as being redundant, but after
> > > reading Dr. Chu's argument, I'm revising my thinking.  For one thing,
> > > this style makes it much less disruptive to change a Moore output to a
> > > Mealy and vise versa.
> > >
> > > My thanks to S.C. for the reference.  Good one.
> > >
> >
> > But in practice one doesn't much care if any outputs are 'Mealy' or 'Moore'.
> > What one has is a function that needs to be implemented within specific area
> > (or logic resource) constraints and performance (i.e. clock cycle, Tpd, Tsu,
> > Tco) constraints.
> >
> > Breaking what can be accomplished in one process into two (or more)
> > logically equivalent processes should be considered for code clarity which
> > can aid in support and maintenance of the code during it's lifetime as well
> > as for potential design reuse (although realistically re-use of any single
> > process is probably pretty low).  Re-use happens more often at the
> > entity/architecture level, but the 'copy/paste/modify' type of re-use
> > probably happens more at the process level when it does happen.
> >
> > Breaking a process into two just to have a combinatorial process to describe
> > the 'next' state and a separate process to clock that 'next' state into the
> > 'current' state has no particular value when using design support and
> > maintenance cost as a metric of 'value'.  Since the different methods
> > produce the final end logic there is no function or performance advantage to
> > either approach.  On the other hand, there are definite drawbacks to
> > implementing combinatorial logic in a VHDL process.  Two of these are
> > - Introduction of 'unintended' latches
> > - Missing signals in the sensitivity list that result in different
> > simulation versus synthesis results
> >
> > Both of these drawbacks have manual methods that can be used to try to
> > minimize them from happening but the bottom line is that extra effort
> > (a.k.a.. cost or negative value) must be incurred to do this....all of which
> > is avoided by simply not using the VHDL process to implement combinatorial
> > logic (i.e. the 'next' state computation).
> >
> > So as far as the VHDL language is concerned, there are real costs that will
> > be incurred every time the two process method is used but no real value
> > add....or at least that's my 2 cents.....
> >
> > KJ
>
> After reading the arguments here, I have started using a mixed
> approach, but I still use the two process model for state machines and
> other complex logic. There are just too many times when I don't want to
> wait until the next clock for an output to take affect.
>
> At work, we have a hard requirement (as in, it won't pass a peer
> review) to write in the two process model. Another hard requirement
> (that I agree with) is that there should only be one clocked process
> per clock. The guy that came up with the requirement predates HDL's in
> general - and I'm sure there was a good reason for it at one time.
>
> However, for my home projects, I tend to mix the one and two-process
> models based on what is most convenient.
>
> Having done so, I don't see that the two-process model is that terribly
> inconvenient. I simply place a default condition at the beginning of
> the process, and override the default as needed. For most processes,
> this adds maybe 1-10 "extra" lines.
>
> Perhaps it's because I was taught in the two-process model, but I find
> it easier to understand what is going on when I use it, so anything
> that requires me to think, I use a separate combinatorial process for.
> Simple logic, like counters, pipeline registers, etc. goes into the
> appropriate clocked process.
> 
> For me, this mixed approach works pretty well.


Article: 105479
Subject: Re: Hardware book like "Code Complete"?
From: Andy Glew <first.last@employer.domain>
Date: 24 Jul 2006 10:12:42 -0700
Links: << >>  << T >>  << A >>
> My impression is that hardware people don't like to write much, and
> even if they do, they don't have time to sit down and document all of
> the important "big issues" that new people need to learn in order to be
> effective.
> 
> But if anyone writes a book like this it will fly off the shelves!

Care to estimate the size of the market?

I.e. how much would the author expect to make, given typical publishing contracts?

(I've long wanted to write such a book, but have trouble with the
business case - i.e. persuading my wife.  And, of course, I cannot
write it as an employee of Intel.)

Article: 105480
Subject: Re: Hardware book like "Code Complete"?
From: "radarman" <jshamlet@gmail.com>
Date: 24 Jul 2006 10:17:06 -0700
Links: << >>  << T >>  << A >>
> > Another hard requirement
> > (that I agree with) is that there should only be one clocked process
> > per clock. The guy that came up with the requirement predates HDL's in
> > general - and I'm sure there was a good reason for it at one time.
> >
> This struck me as kind of odd.  I understand that if there is a hard
> requirement to do it this way then you either will do it that way or
> seek other employment.  I also don't find it hard to believe either
> that the reason for the requirement for may predate HDLs and there was
> a good reason for it at one time.
>
> What I find odd though is that you agree with it.  Based on your other
> posts to this group I could see that you could 'accept' that this is
> how you have to do it but I guess I'm surprised that you would 'agree
> with' something that you don't know what the reasoning is...doesn't
> seem like 'radarman' talking.

I've been bitten in the hindquarters with cross-clock domain problems
too many times. I now have one clocked process per clock. While I try
to avoid cross-clock asynchronous resets, occasionally (especially in
CPLD's) there is no other choice.

I find that by doing this, I catch clock domain crossing errors more
easily. For example. On one design, I had a bus interface running on a
fixed clock (32MHz), internal logic on another fixed clock (40MHz), a
state machine that controlled a digital synthesizer (DDS 9858) that ran
on the DDS utility clock (40MHz, but asynchronous to the previous
clock), and a whole other section of code that ran on the clock
generated by the synthesizer (approximately 40MHz, but variable within
a band).

To summarize:
Local bus clock -> 32MHz.
Local bus I/F and control -> 40MHz (fixed)
DDS controller -> 40MHz (frequency locked, but not phase locked to the
previous)
"special logic" -> 38MHz < f < 42MHz from DDS.

Now, in most cases I was able to limit the crossings. There were a few
F40 <-> V40 crossings due to the nature of the design, but I tried to
restrict those to a handful of sentinel signals with strict timing, and
used rate-change FIFO's where timing wasn't critical. To simplify
things a bit, I created two copies of the bus interface - one for the
40MHz fixed, and another for the 40MHz variable.

However, in the actual DDS controller, I had all three clocks in play
at once. My design had to be able to frequency and phase lock the DDS
output frequency to the fixed 40 (which is quite doable, even if the
design to do so "looks" terrible). To make things more fun, it had to
issue the controls to the DDS aligned with the DDS utility clock - so
the state machine ran on that clock domain. Thankfully, the DDS utility
clock was reliably 90 degrees out of phase with the F40 domain, so I
could design a proper clock boundary crossing circuit.

The one time I fooled around with multiple clocked processes and
multiple clock domains, I ended up spending days (weeks?) debugging a
pernicious little problem that took hours of operation to fail. I
accidentally clocked something that was in the fixed 40MHz domain with
the variable 40MHz. It took a long time to debug that problem because
the per-operation error was so small. Unfortunately, even though the
error was only +/- a few nanoseconds worst case, it was cumulative, and
would cause the system to fail eventually.

While I would have been given leave to violate the design guidelines
with that module, given the complexity of the clock domain crossings, I
found it was better to follow them. Eventually, it dawned on me that a
certain register was in the wrong process. By putting all of the
registers for each domain in a single process, I was able to wrap my
head around the problem more easily.

As a result of that experience, I also started adding the clock domain
as a suffix to the signal name in complex designs. It leads to long
names, but it is worth the effort.


Article: 105481
Subject: EDK Using External Ports to toggle FPGA pins
From: "Kyle H." <kyle.hable@gmail.com>
Date: 24 Jul 2006 10:20:01 -0700
Links: << >>  << T >>  << A >>
Hello All,

I am having a hard time understanding EDK  ---> FPGA tool flow (I
think).  I am using EDK/ISE 8.1, testing the Generic Reference Design
from Memec/Avnet.  It is for the Xilinx FX12 mini-module.

I have been able to use the drivers supplied to control the LCD screen,
rs232 uart and the user LEDs as expected.  But when it comes to a
specific FPGA pin of my choice I'm getting lost.

I first started out with their example, and created my own spin off of
theirs, trying to learn my way around the IDE of EDK.  All is working
well except my understanding of the UCF file corresponding to the data
inside EDK.  Ok, so in my xparameters.h file I see there are
refferencing the memory locations for each component in the system
assembly.  So in C I can assign these "registers" via the drivers and
get expected results.  When it comes down to bit by bit I am lost.

Is the UCF file that I'm using generated by EDK, or did someone from
memec hand sculpt this?
Maybe I have to import this into an ISE project to get the big picture?

When I assign a gpio output 0x0550 I can see one 5 on my FPGA pins, but
not in the order I would expect it.  Really it's not a five at all,
unless I'm reading all the even pins.  And I thought the gpio output
was 32 bit, so why in the UCF file is there only 10 pins assigned to
the gpio output port(s)?

I hope I am not being to vague/mis-guided, and even confusing you guys.
Because I have certianly exhausted my confusion.  I've also read over a
ton of documentation from XIlinx, about EDK, the drivers, etc...  I was
searching for that golden document that would tell me exactly what I
needed to know and I havn't found it yet.  Maybe I am not looking for
the correct topics in the manuals?  Maybe I need to read over PowerPC
user guide a bit more?
Help point me in the wright direction!

Thanks,
Kyle


Article: 105482
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 24 Jul 2006 10:20:30 -0700
Links: << >>  << T >>  << A >>
KJ wrote:


> By the way, if you do find the 'good' reason for having physically only
> one clocked process I'd be curious to hear what it is. 

No signal declarations or direction
conflicts to worry about.
Output register variable values
are assigned directly to out ports.

         -- Mike Treseler


Article: 105483
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 24 Jul 2006 10:36:51 -0700
Links: << >>  << T >>  << A >>
Andy Glew wrote:

> Care to estimate the size of the market?

2000-4000 copies over 2 years.
> 
> I.e. how much would the author expect to make, given typical publishing contracts?

Maybe $4 per book.

> (I've long wanted to write such a book, but have trouble with the
> business case 

There isn't one.
You would have to do it for love, not money.

> And, of course, I cannot
> write it as an employee of Intel.

I expect that would be negotiable.
RTL design is hardly proprietary.

       -- Mike Treseler




Article: 105484
Subject: Re: ROM implementation
From: "Andy" <jonesandy@comcast.net>
Date: 24 Jul 2006 10:37:04 -0700
Links: << >>  << T >>  << A >>
Do Actel Block RAMs require registered reads (one clock delay from addr
to data)?  That may be your problem if your RTL does not mimic that
behavior.

Andy


gollum wrote:
> I have a 256x8 bit look up table in my vhdl design and I reach this
> look up table 64 times.
>
> I am using Synplify 8.6.1 to synthesize my code for ACTEL Ax or Proasic
> family and tool infers a lot of ROMs for this table.
>
> As soon as I understand this inferred ROMs are made up of logic gates
> not reserved block Rams in the technology.
>
> I heard that there is an attribute for Xilinx Virtex family named
> "select_ROM" in order to use block Rams instead of wasting logic gates
> of resources.
>
> Is there any attribute for Actel family?
> 
> 
> I would appreciate your help.


Article: 105485
Subject: Re: Hardware book like "Code Complete"?
From: "Dean Kent" <dkent@realworldtech.com>
Date: Mon, 24 Jul 2006 10:44:54 -0700
Links: << >>  << T >>  << A >>
At least one.  I'd buy it.   ;-).

Suggestion:  Do it like the guy who wrote "Thinking in JAVA" did.  As he
finished a chapter, he posted it on his website for people to review.   He
got tons of corrections and feedback, which he then used to update the
chapter.   At the end of it all, he published a hardcopy and to his surprise
found out he sold more than expected - because everyone who had read it
online wanted a copy on his/her desk, and because it was online originally
it was highly anticipated when it was actually published.

Seems counter-intuitive, but I believe it would work for a tome such as
this... (and if you did it right, you could generate a few bucks before it
every gets published, wink-wink, nudge-nudge, hint-hint,
know-what-I-mean--know-what-I-mean?).

Regards,
   Dean

"Andy Glew" <first.last@employer.domain> wrote in message
news:peyp8xmjgc51.fsf@PXPL8591.amr.corp.intel.com...
> > My impression is that hardware people don't like to write much, and
> > even if they do, they don't have time to sit down and document all of
> > the important "big issues" that new people need to learn in order to be
> > effective.
> >
> > But if anyone writes a book like this it will fly off the shelves!
>
> Care to estimate the size of the market?
>
> I.e. how much would the author expect to make, given typical publishing
contracts?
>
> (I've long wanted to write such a book, but have trouble with the
> business case - i.e. persuading my wife.  And, of course, I cannot
> write it as an employee of Intel.)



Article: 105486
Subject: Re: Hardware book like "Code Complete"?
From: "David Kanter" <dkanter@gmail.com>
Date: 24 Jul 2006 11:34:45 -0700
Links: << >>  << T >>  << A >>
[snip]

I think what Dean means to say is that he knows an excellent, reputable
website that would put something online and attract a lot of good
readers : )

And if you do a good job, I bet you could persuade Intel to start
buying up copies in bulk for NCGs.

DK


Article: 105487
Subject: Soft processor performance
From: "baboonspanker@fastmail.fm" <baboonspanker@fastmail.fm>
Date: 24 Jul 2006 11:37:32 -0700
Links: << >>  << T >>  << A >>
I see that Xilinx claim 0.92 Dhrystone 2.1 mips/Mhz for Microblaze and
Altera varously up to 1.2 dmips/Mhz. Does anyone know if these are
measured with inlining enabled? I found Xilinx XAPP507 which implies
that their headline "DMIPS" figure for the embedded powerPCs is with
inlining enabled but I can't find anything similar for the soft cores.


Article: 105488
Subject: Re: Hardware book like "Code Complete"?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 24 Jul 2006 12:20:15 -0700
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
> KJ wrote:
>
>
> > By the way, if you do find the 'good' reason for having physically only
> > one clocked process I'd be curious to hear what it is.
>
> No signal declarations or direction
> conflicts to worry about.

You have variable declarations instead....not sure what 'direction
conflicts' you're talking about but if it's multiple processes both
'outputting' some signal than not using 'resolved' logic types allows
the compiler to catch that straight out also.

> Output register variable values
> are assigned directly to out ports.
>
And this is better (or just different) than output register signals
values being assigned to out ports?

KJ


Article: 105489
Subject: Re: Hardware book like "Code Complete"?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 24 Jul 2006 12:36:11 -0700
Links: << >>  << T >>  << A >>

radarman wrote:
> Eventually, it dawned on me that a
> certain register was in the wrong process. By putting all of the
> registers for each domain in a single process, I was able to wrap my
> head around the problem more easily.
>
> As a result of that experience, I also started adding the clock domain
> as a suffix to the signal name in complex designs. It leads to long
> names, but it is worth the effort.

OK, good explanation, I wasn't immediately considering the entities
with several clocks in them.  I'd submit though that most of the real
value was in the naming convention of adding the clock domain suffix to
the signal name (which is something that I do as well by the way) and
not so much that they were all physically in one process.

If you agree that the naming convention was probably the more important
of the two then from your description it appears that 'the company'
didn't have signal naming rules in place....and that would've been a
bigger help if it did.  In other words,  the clock domain suffix
certainly would qualify as one of those 'good' patterns for all to
follow and your problem description is a case for why.

The jury is still out in my mind on the physically one clocked process
requirement, to me it can lead to a lot of scrolling back and forth to
make sure one understands all of the places where signals get assigned.
 But I'll also accept that in the multi-clock entities that one needs
to be even more rigid than usual since the tools are of almost no help
in helping to make sure you're crossing domains properly.....and dang,
why is that anyway it's not like it brain surgery.

KJ


Article: 105490
Subject: Re: ByteBlasterMV?
From: Ben Jackson <ben@ben.com>
Date: Mon, 24 Jul 2006 14:39:06 -0500
Links: << >>  << T >>  << A >>
On 2006-07-24, Clifford Heath <no@spam.please.net> wrote:
>
> The MV uses a 74HC244 instead of the LS one, and that means

A LOT of target-powered parallel port programming dongles use the HC244
with 3V targets.  I've used the Byteblaster you mentioned, as well as
the Kanda AVR programmer (w/ 3V target).

> '244 running at 3.3v, for example, won't the parallel port
> cause latchup by pulling the inputs too high?

If you look at a datasheet you'll see the input clamp current is 20mA,
so you could work it out from that.

In practice, though, most of those dongles use a diode between target
VCC and power, so the target can't actually sink any current at 3V,
so the 5V that gets through the protection diodes on the HC244 probably
just raises its supply rail above the target voltage.  So really it'd
be the target that would see higher voltages.

Anyway, I'd leave out the resistors.  The last programming dongle I made
used a 1k resistor for the return (between the buffer and the parallel
port).  Looked fine on a scope, didn't work.  Shorted it out, worked fine.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 105491
Subject: Re: Hardware book like "Code Complete"?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 24 Jul 2006 12:42:22 -0700
Links: << >>  << T >>  << A >>

> Many hands make light work. Get a couple of dozen of
> experienced designers, a bunch of proof reading fact
> checkers and one decent editor and you  got yourself
> an open source book writing project.
>
> Put it out on sourceforge for free and make it useful for any
> digital designer at any stage in their career or hobby.Do
> a really good job and it can become the "bible" of the
> industry that everyone has in the library.
>
Certainly an interesting idea.
>
> Do we have the critical mass to pull something like this off?
>
Always a big question...the other important question is finding the
'leader' to prod this along to get it going in the first place.

KJ


Article: 105492
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 24 Jul 2006 13:12:53 -0700
Links: << >>  << T >>  << A >>
KJ wrote:

> You have variable declarations instead....not sure what 'direction
> conflicts' you're talking about but if it's multiple processes both
> 'outputting' some signal than not using 'resolved' logic types allows
> the compiler to catch that straight out also.

True. My point is that keeping track of signal
direction relative to each process is manual
bookkeeping that I don't have to with a single process.

>> Output register variable values
>> are assigned directly to out ports.
>>
> And this is better (or just different) than output register signals
> values being assigned to out ports?

Simpler because *all* of my registers are variables.
There is no need to interpose a signal. Just

   my_out_port <= my_out_reg_v;


        -- Mike Treseler

Article: 105493
Subject: Correlator block
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 24 Jul 2006 13:12:59 -0700
Links: << >>  << T >>  << A >>
Hi,
I am trying to implement a correlator block in a Virtex-4 FPGA. This
FPGA is connected to an ADC08D1500 chip and the board is set up such
that 4096 samples are collected and the 8-bit data is sent to the USB
controller which in turn serializes it and sends it to the host PC.
Initially I thought of going ahead with the bit correlator, but that's
not what I want. I want a 2 input corrrelator that correlates the data.
Let me know if anyone has a sample code or has experience working with
National Semiconductor ADC08D1500 dev board.
Thanks,
Vivek


Article: 105494
Subject: Re: Hardware book like "Code Complete"?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 24 Jul 2006 13:33:25 -0700
Links: << >>  << T >>  << A >>

Andy wrote:
> With variables, you don't have to wait an extra clock in single process
> descriptions.
>
With concurrent signal assignments that are outside of the process you
don't have to wait an extra clock either.

KJ


Article: 105495
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 24 Jul 2006 13:38:59 -0700
Links: << >>  << T >>  << A >>
EEngineer wrote:
>  I use:
> 
> Service Pack 1
> 

I would definitely try upgrading to Service Pack 3.

Ed McGettigan
-- 
Xilinx Inc.

Article: 105496
Subject: Re: Hardware book like "Code Complete"?
From: Paul Floyd <root@127.0.0.1>
Date: 24 Jul 2006 20:42:20 GMT
Links: << >>  << T >>  << A >>
On 24 Jul 2006 10:12:42 -0700, Andy Glew <first.last@employer.domain> wrote:
>> My impression is that hardware people don't like to write much, and
>> even if they do, they don't have time to sit down and document all of
>> the important "big issues" that new people need to learn in order to be
>> effective.
>> 
>> But if anyone writes a book like this it will fly off the shelves!
>
> Care to estimate the size of the market?

I can't guess that.

> I.e. how much would the author expect to make, given typical publishing contracts?
>
> (I've long wanted to write such a book, but have trouble with the
> business case - i.e. persuading my wife.  And, of course, I cannot
> write it as an employee of Intel.)

From the software world, I suggest that you take a look at Scott Meyers
web site: http://www.aristeia.com/authorAdvice_frames.html

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.

Article: 105497
Subject: Re: Hardware book like "Code Complete"?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 24 Jul 2006 13:50:08 -0700
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
> KJ wrote:
>
> > You have variable declarations instead....not sure what 'direction
> > conflicts' you're talking about but if it's multiple processes both
> > 'outputting' some signal than not using 'resolved' logic types allows
> > the compiler to catch that straight out also.
>
> True. My point is that keeping track of signal
> direction relative to each process is manual
> bookkeeping that I don't have to with a single process.
>
But if you use an unresolved type you're not doing the bookkeeping
either, the compiler is when it complains about multiple drivers on an
unresolved signal.  If you assume that the designer can have a brain
fart and try to drive signal 'XYZ' from two processes then you also
have to accept that the same designer could have two equations for
'XYZ' in the 'one' process.  Assume for the moment that one of those
two is correct.  If those two equations are in separate processes the
compiler immediately flags it as an error, if they are all in one
process then you've basically priority encoded those two equations.
Since we assumed that the designer had a momentary brain fart
forgetting about the other assignment that already existed, which
method allows you to fix the bug quicker?

> >> Output register variable values
> >> are assigned directly to out ports.
> >>
> > And this is better (or just different) than output register signals
> > values being assigned to out ports?
>
> Simpler because *all* of my registers are variables.
> There is no need to interpose a signal. Just
>
>    my_out_port <= my_out_reg_v;
>
>
I'll go with just 'different' on this one, it doesn't seem better,
worse or simpler to me since the only reason for that line of code is
because the probably more logically complicated assignment that occurs
to the variable could just as easily have assigned it to the output
signal in the first place.  But there are times when even I use
variables inside a clocked process too so I don't really disagree.

KJ


Article: 105498
Subject: Re: Soft processor performance
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 24 Jul 2006 13:58:27 -0700
Links: << >>  << T >>  << A >>
baboonspanker@fastmail.fm wrote:
> I see that Xilinx claim 0.92 Dhrystone 2.1 mips/Mhz for Microblaze and
> Altera varously up to 1.2 dmips/Mhz. Does anyone know if these are
> measured with inlining enabled? I found Xilinx XAPP507 which implies
> that their headline "DMIPS" figure for the embedded powerPCs is with
> inlining enabled but I can't find anything similar for the soft cores.
> 
Can't say for Altera but for MicroBlaze we disable inlining while doing 
dhrystone benchmarks since the idea behind the dhrystone benchmark 
requires a percentage of procedure calls.
Inlining would remove that.
I think it would violate the main idea behind the dhrystone benchmark.

We get a higher DMIPS/MHz if we allow inlining.
And to make sure that no inlining is done we compile with the 
'-fno-inline' flag to GCC.
If we don't have that flag, the amount of inlining depends on the 
version of GCC since they difference in the amount of inlining.

Göran Bilski

Article: 105499
Subject: Re: chipscope opb monitor
From: sunwei388@gmail.com
Date: 24 Jul 2006 14:09:13 -0700
Links: << >>  << T >>  << A >>

Siva Velusamy wrote:
> Check your trigger conditions. In the trigger window, apart from
> specifying the value for each trigger, you also have to mention exactly
> which trigger condition (or a boolean combination of conditions) needs
> to be enabled.
>
> /S
>
> Frank van Eijkelenburg wrote:
> > I try to use the opb/iba unit of chipscope to monitor the opb bus within
> > a simple edk design. I took the chipscope lab example as start point. I
> > am able to see the OPB signals in chipscope, but I can not set a trigger
> > point. For example, I want to trigger at a certain address 0xFFFFXXXX.
> > If I wait for the triggercondition, the behaviour is the same if no
> > condition is set (like the immediate trigger button is clicked). Another
> > problem is: I don't see assembly or c-source code in the listing window.
> > Do I have to tell chipscope where it can find sources? What could be wrong?
> >
> > In the lab example there are three control ports instantiated at the
> > ICON unit while only two ports are connected. I have two control ports
> > instantiated and connected, because ISE failed at the unconnected
> > control port (in the map phase).
> >
> > Any ideas?
> > Frank

Hello Frank, Siva,

I am also working on chipscope but it doesn't work. The error message
is very strange and I suppose it is an assertion error. I use EDK8.1
SP2, ISE8.1 SP3 and Chipscope 8.1SP3. Can you tell me what is your
configuration? Thanks a lot.

Sunwei




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