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 118775

Article: 118775
Subject: Re: Wait-for / until won't work ? Xilinx Spartan 3
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Thu, 3 May 2007 15:26:42 +0100
Links: << >>  << T >>  << A >>

"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message 
news:f1ci9j$80t$1@news.lysator.liu.se...
> On 2007-05-03, Andy <jonesandy@comcast.net> wrote:
>
> So I'd summarize the advantages/disadvantages like this:
>
> wait until rising_edge(clk):
>   + No sensitivity list to worry about
>   + No asynchronous behaviour to worry about
>   - Might lead students to use wait in ways they shouldn't
>
> if rising_edge(clk) then:
>   + No wait statement
>   + A bit more general
>   - Fully legal to create asynchronous logic, including latches
>   - Sensitivity list to worry about

Those are by no means the only options. For example:

  process (clock)
  begin
    if rising_edge(clock) then

      -- Put your RTL code in here

      if reset = '1' then

        -- Put the code that resets any signals that need resetting in here

      end if;

    end if;
  end process;

Pros/cons:
  + No wait statement
  + Completely general
  + No asynchronous behaviour to worry about
  + No sensitivity list to worry about
  + Efficient (sync) resets for signals that need them
    but with no penalty for signals that don't
  - ???

      -Ben- 



Article: 118776
Subject: Re: Xilinx software quality - how low can it go ?!
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Thu, 3 May 2007 15:34:43 +0100
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1178200918.376020.170930@u30g2000hsc.googlegroups.com...
On 2 Mai, 19:44, dalai lamah <antonio12...@hotmail.com> wrote:
> Un bel giorno Antti digiṭ:

> > Actually some bugs and missing features - especially in the user 
> > interface
> > - are quite funny, for example the editor that hangs forever if you try 
> > to
> > use the dead keys (i.e.http://en.wikipedia.org/wiki/Dead_key). Or is it
> > just me?
>
> My god, you are right!
> Just tried out in ISE 9.1 in ucf editor ... it really hangs !!!!
>
> Well the workaround is simple, not to use dead keys. But its really
> hard to imagine how some company is able to develop software with such
> bugs!

This might, of course, be an underlying bug in the Qt widgets that the 
ISE/XPS GUIs use... what OS are you talking about? I know that many of 
Microsoft's own programs have (more minor) problems with dead-key handling; 
I ended up turning off the International keyboard features because they just 
didn't work properly in too many applications... :(

> So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need
> kill and loose changes!), is minor, some other issues with EDK 9.1 are
> not:

Needless to say, I know lots of people who are succesfully running EDK 9.1i 
and ISE 9.1i, with and without the various service packs and IP updates, who 
haven't reported any problems at all. I am one of them. Perhaps the setup of 
my environment is much simpler that yours?

Cheers,

      -Ben- 



Article: 118777
Subject: Re: Wait-for / until won't work ? Xilinx Spartan 3
From: Paul <pauljbennett@gmail.com>
Date: 3 May 2007 07:40:59 -0700
Links: << >>  << T >>  << A >>
As far as I've heard/seen in large companies with regulated coding
styles,
the wait statement version of a DFF is considered to be sloppy for
readability maintainability purposes.  tick-event is considered a much
cleaner way of coding a DFF.

As for the original question:
Buy a book on synthesizable VHDL and lookup "counter" in the index
But it will go something along the lines of

if count = "00000000" then
  enable  <= '1';
else
  enable  <= '0';
end if;

Obviously that needs to be within a  process and all that jazz.  But
definately buy a good
book on SYNTHESIZABLE vhdl.... 70% of the language is non-
synthesizable, not knowing
which parts that is makes it very useless for you as a designer.  Wait
statements, time, etc.. would
have been included in chapter 1 just about of any decent synthesis
book.  When I took
my vhdl class in undergrad we used VHDL Primer - which in retrospect
is a poor book in terms
of seperating synthesizable from non-synthesizable constructs.  I used
the andrew rushton in a graduate
class recently - much, much better.



On May 3, 7:50 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote:
> On 2007-05-03, Andy <jonesa...@comcast.net> wrote:
>
> > You cannot wait for TIME in synthesizable code.  You can wait until
> > rising_edge(clk)! Not usually the best coding style, but it can be
> > done and is accepted by most synthesis tools.
>
> I was also of the opinion that it wasn't a very good coding style but
> after a couple of years of basic VHDL teaching I think it is actually
> better to say that a sequential process looks like this:
>
>   process
>   begin  -- process
>     wait until rising_edge(clk);
>     -- Some code...
>   end process;
>
> The "standard" alternative is this:
>
>   process (clk)
>   begin  -- process
>     if clk'event and clk = '1' then  -- rising clock edge
>         -- Some code...      
>     end if;
>   end process;
>
> The problem with the second one is that first time students are likely
> to produce something like:
>
>   process (clk)
>   begin  -- process
>     if rst = '1' then
>       foo <= (others => '0');
>     end if;
>
>     if clk'event and clk = '1' then  -- rising clock edge
>       -- Some code...
>     else
>       somethingelse <= '0';
>     end if;
>   end process;
>
> This kind of unholy synchronous/asynchronous process will usually be
> accepted by the synthesis tool and work badly, if at all whereas it
> is not possible to create any asynchronous behaviour if the first version
> is used. (Or rather, synthesis tools will not allow it)
>
> So I'd summarize the advantages/disadvantages like this:
>
> wait until rising_edge(clk):
>    + No sensitivity list to worry about
>    + No asynchronous behaviour to worry about
>    - Might lead students to use wait in ways they shouldn't
>
> if rising_edge(clk) then:
>    + No wait statement
>    + A bit more general
>    - Fully legal to create asynchronous logic, including latches
>    - Sensitivity list to worry about
>
> /Andreas



Article: 118778
Subject: Re: Wait-for / until won't work ? Xilinx Spartan 3
From: Paul <pauljbennett@gmail.com>
Date: 3 May 2007 07:57:30 -0700
Links: << >>  << T >>  << A >>
Incorrect, the above example is not in fact easy to synthesize, at
least not in the fashion the person
presumably wanted it to synthesize...

first off.. it need to be in a process... "wait until" makes no sense,
even for a testbench, in
the context of a concurrent statement

so lets assume it was meant to be put in a process:

process
begin
signal <= '0';
wait until count = 0;
signal <= '1';
end process;

even in simulation, the signal will never change from a 0.  it will
set it to a '1', the activity on signal will reactivate the process
and it will in 1-delta time set back to a 0, never changing in
"real" (non-delta) time!  sure the synthesizer could tie 'signal'  to
ground, but i dont think that was the intent...

so lets give the person the benefit of the doubt...  write it like it
was a testbench

signal <= '0';
wait until count = 0;
signal <= '1';
wait;

pause the process indefinately (as far as simulation is concerned)
after it sets signal to '1'.  but wait... count is a flip flop..
so we compare count with 0, AND the output of the comparison with a
'1' and that's our signal, right?  but wait
what happens on reset?  the flop is reset, and signal goes back to a
'0'... probably what we WANTED, but not what our code describes, and
not what a simulator would tell you it's gonna do!  so to make this
match simulation, signal must go into a latch, a real, honest, level-
sensitive latch... not an enabled DFF, because that would clear on
reset, which according to our code is NOT what we wanted....  but that
latch is a timing nightmare and almost NEVER recommended in an FPGA...
probably not what we actually wanted, but indeed the only way our
synthesizer can accurately synthesize the code we wrote to match
simulation (i.e. match what our code describes)

Still think this is a deficiency of the tool??


> Indeed, you can't. But I consider this to be a deficiency of the
> tools. The above example is
> easy to synthesize. There have been academic proofs of concept decades
> ago.
> Essentially you only need to add a state per wait statement.
>
> Kolja Sulimma- Hide quoted text -
>
> - Show quoted text -



Article: 118779
Subject: Re: Problem with writing values to SRAM from XMD
From: Roman <plyaskin@googlemail.com>
Date: 3 May 2007 07:59:13 -0700
Links: << >>  << T >>  << A >>
On Apr 26, 12:03 pm, Newman <newman5...@yahoo.com> wrote:
> On Apr 25, 11:37 am, Roman <plyas...@googlemail.com> wrote:
>
>
>
> > Hello!
>
> > I am using a board with Virtex4 PPC405, external asynchronousSRAM
> > memory and EDK 8.2i. If application program resides in BRAM and I want
> > to write and read fromSRAM, it is only possible if there is
> > instruction and data cache enebled and I add XCache_EnableCache in the
> > beginning of the code. So far it works. Then I tried to run
> > application fromSRAM. So I generated linker script telling that the
> > program should be inSRAM. After I launched XMD and entered
>
> > dow executable.elf
> > run
>
> > it didn't work. When I tried to read downloaded code by mrd command
> > fromSRAM, it showed zero values.
> > Furthermore, I tried to explicitly write a value toSRAMwith mwr
> > command and read it afterwards, it showed zero value again.
>
> > So I thought the problem is that cache is still not enabled (because
> > code is not running and XCache_EnableCache function was not executed).
> > Then I set in XMD debug options "Set XMD memory map for  PPC405
> > features" where it is possible to enable caches, but it didn't help.
>
> > Parameter C_INCLUDE_BURST_CACHELN_SUPPORT in .mhs file is set to 1.
>
> > Does anybody have any suggestions what it could be?
> > Thanks in advance!
>
> > Best regards
> > Roman
>
> One way to track down the problem is to look at thesramlines with
> chipscope stimulating it with mwr, mrd.  It could be that you were
> fooled in the first example, and data reads and writes looked good
> because they were being accessed via the cache only, and not beiIng
> posted to thesram.
>
> I believe chipscope is a good investment for what you are doing.  A
> free evaluation is available from Xilinx.
>
> Newman

Thanks a lot! There was a problem with physical connection to SRAM.


Article: 118780
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 3 May 2007 08:13:00 -0700
Links: << >>  << T >>  << A >>
Ben Jones schrieb:
> "Antti" <Antti.Lukats@xilant.com> wrote in message
> news:1178200918.376020.170930@u30g2000hsc.googlegroups.com...
> On 2 Mai, 19:44, dalai lamah <antonio12...@hotmail.com> wrote:
> > Un bel giorno Antti digit=F2:
>
> > > Actually some bugs and missing features - especially in the user
> > > interface
> > > - are quite funny, for example the editor that hangs forever if you t=
ry
> > > to
> > > use the dead keys (i.e.http://en.wikipedia.org/wiki/Dead_key). Or is =
it
> > > just me?
> >
> > My god, you are right!
> > Just tried out in ISE 9.1 in ucf editor ... it really hangs !!!!
> >
> > Well the workaround is simple, not to use dead keys. But its really
> > hard to imagine how some company is able to develop software with such
> > bugs!
>
> This might, of course, be an underlying bug in the Qt widgets that the
> ISE/XPS GUIs use... what OS are you talking about? I know that many of
> Microsoft's own programs have (more minor) problems with dead-key handlin=
g;
> I ended up turning off the International keyboard features because they j=
ust
> didn't work properly in too many applications... :(
>
> > So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need
> > kill and loose changes!), is minor, some other issues with EDK 9.1 are
> > not:
>
> Needless to say, I know lots of people who are succesfully running EDK 9.=
1i
> and ISE 9.1i, with and without the various service packs and IP updates, =
who
> haven't reported any problems at all. I am one of them. Perhaps the setup=
 of
> my environment is much simpler that yours?
>
> Cheers,
>
>       -Ben-

Hi Ben,

agreed, there are very likely plenty of EDK 9.1 installation that work
OK.
my own experience so far is 3 out 3 have problems, either minor or
showstoppers.
3 out of 3 is too small criteria of course. but I have to find
workaround to get
those 3 all working also :(, 1 is ok 2 still refuse to work properly.

BTW the % amount of succesful Xilinx software tool installations
within
Xilinx and outside may be quite different.

actually I think the amount of success (installing Xilinx software)
inside Xilinx
should not be counted at all, only the success-failure ration for
installations
done outside.

Antti


Article: 118781
Subject: Re: debounce state diagram FSM - topical
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 03 May 2007 08:16:51 -0700
Links: << >>  << T >>  << A >>
On Thu, 03 May 2007 08:41:34 +0100, Flash Gordon
<spam@flash-gordon.me.uk> wrote:

>John Larkin wrote, On 03/05/07 01:09:
>> On Wed, 02 May 2007 22:59:08 +0100, Flash Gordon
>
><snip>
>
>>> Why do you think it reasonable for us to have to put up with 
>>> inappropriate cross-posts and not for you to put up with polite requests 
>>> to stop the cross-posts?
>> 
>> You're right, engineers and programmers should communicate as seldom
>> as possible.
>
>OK, so you are incapable of reading, understanding or answering 
>questions even when those you are responding to are staying polite.
>
>For the record, I have never said engineers and programmers should not 
>communicate, and I have worked very closely with HW people in the past 
>where it was appropriate. However, that still does not, and never can 
>make, posting stuff in comp.lang.c about how to design the HW 
>appropriate in comp.lang.c
>
>Note that the only comment I got when asking if posting physics 
>questions to the other groups was a post saying one of the groups was 
>already being invaded by trolls, not a response saying that it would be 
>acceptable. So you obviously only care about the topicality of YOUR 
>group(s) and sod everybody else.


s.e.d. routinely discusses electronic circuit design, thermal design,
mechanics and materials properties, manufacturing and economic issues,
fpga design, uPs/firmware/dsp/numeric algorithms, operating systems,
and computer languages. In a real electronic design, all these must be
accounted for and all trade off against the others. If switches
bounce, there are a number of solutions, the cheapest and most
reliable (assuming no coding bugs!) being to do it in software.

I'm always interested in how hermetic some disciplines are, how
intense some programmers are to keep the programming pure, to abstract
away the real world, and to do their best to know nothing about the
environment their programs actually live in; hence comments like
"switch debouncing is best done in hardware." 

I mean, if all you know is programming, how do you find a problem to
program? Do you depend on an exhaustive specification that's created
by someone else who understands the end application, so you don't have
to get involved? Would you ever look at a switch datasheet to see how
long it might bounce?

John




Article: 118782
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 3 May 2007 08:25:08 -0700
Links: << >>  << T >>  << A >>
Ben Jones schrieb:
> "Antti" <Antti.Lukats@xilant.com> wrote in message
[]
> This might, of course, be an underlying bug in the Qt widgets that the
> ISE/XPS GUIs use... what OS are you talking about? I know that many of
> Microsoft's own programs have (more minor) problems with dead-key handling;
> I ended up turning off the International keyboard features because they just
> didn't work properly in too many applications... :(
>
> > So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need
> > kill and loose changes!), is minor, some other issues with EDK 9.1 are
> > not:
>
> Needless to say, I know lots of people who are succesfully running EDK 9.1i
> and ISE 9.1i, with and without the various service packs and IP updates, who
> haven't reported any problems at all. I am one of them. Perhaps the setup of
> my environment is much simpler that yours?
>
> Cheers,
>
>       -Ben-

Ben,

there are NO EXCUSES for bad software.

if there problems are Qt widgets, then:
1) fix the problems
2) seek help
3) stop using Qt widgets

if the problems are related to cygwin, then
1) fix the problems
2) seek help
3) stop using cygwin

now, to my 3 EDK installations:
issue 1) is fixed
issue 2) - I have just been able to trace the problem to make version
issue! , this is nothing new. it happened once before with some Xilinx
updates, so it looks that it just re-appeared.. think I can fix it, so
after that  I can say that 2 out 3 work AFTER fixing them post-install

Antti


Article: 118783
Subject: Re: Unused Pin setting on per-pin basis
From: radarman <jshamlet@gmail.com>
Date: 3 May 2007 08:57:21 -0700
Links: << >>  << T >>  << A >>
On May 2, 4:15 am, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> comp.arch.fpga wrote:
>
>  > What do you need the per pin configuration for? The pullups are
>
> > extremely
> > week. (5uA to 200uA for Virtex-4). I can't imagine a digital
> > application that
> > will be disturbed by that.
>
> The board uses a with a Spartan-3E. The data sheet suggest the pull down
> is 34K5 (Table 77 - ds312). I guess that's not too strong.
>
> However, I'd prefer the option to control the pull resistors on a
> per-pin basis. It just seems to me a 'better' way of doing things.
>
> Thanks for the suggestions
> Andy

You should be able to alter the UCF to add the pull-up / pull-downs,
though the resistor is permanently enabled after configuration. (you
can't control it from the fabric) You can use this feature to
eliminate external resistors with great effect.  For example, I have a
small add-in board that doesn't supply a proper VCC, so I use the
internal pull-up to keep the reset line high, and use a switch to
short the circuit to ground. Perhaps not the safest circuit, but it
works.

Of course, if the peripheral really is unused, and you just want to
keep the device in a low-power/safe state, why not just drive the I/O
directly from the VHDL? For example, right now I'm using a ComBlock
board that has no free-running oscillator connected to the FPGA.
Instead, you have to get your clock from the USB PHY, which only
produces said clock after you drive its SUSPENDN signal high. (Of
course this signal is pulled low, so your firmware has to pull it
high, then hold the DCMs in reset until the output clock is stable...)
I just have a line in the VHDL that directly drives that signal high.


Article: 118784
Subject: Re: Video scaler for Spartan 3E?
From: Paul <pauljbennett@gmail.com>
Date: 3 May 2007 09:16:11 -0700
Links: << >>  << T >>  << A >>
Ken,

  Just out of curiosity, what is your timeline on this project??
You've been asking about this for months on here! (That's what all
your DDR interface questions were about, no?)

   There's all sorts of considerations here...

   What is your input data format? Composite video? RGB? etc.. Some
sort of computer driven RGB input would probably be your simplest as
you'll be receiving your three colors seperately and you can just
sample them as 3 input streams.  But you're gonna have lots of
learning and educating yourself to do on sync timing and all that fun
stuff - Keep in mind, most analog video signals were designed to be
fairly crude signals to drive a big honking electromagnetic coil that
certainly didnt respond anything close to the clock rate of your
spartan.  Therefore, putting them into the digital world in some sorta
of useful form can be a bit tricky - basically you need to look for
your syncs and count out to where your first pixel is supposed to
be.

   What are your input & output resolutions? frame rates?  If you're
going 10x10 to 20x20 at 5 fps, I'd bet you could do that in a
Spartan3... 640x480 input at a 60hz refresh, I don't really know -
that's where you're going to have to sit down and run some
calcuations.  Go to your school's library and take out some books on
image processing or multi-dimensional DSP... you're gonna need to
learn some basic image processing first to get an idea of what
operations need to be done before you can begin to grasp the size of
the part you need.

   How accurate do your interpolations need to be?  Think basic 1-
dimensional DSP.. how do you upsample a signal?  insert zeros between
samples and LPF, right?  Or do the same thing in the F-domain by zero
padding the ends of the FFT and inverse-FFT'ing.  Either of these
methods in 2 dimensions is going to be a lot of computation and a lot
of taking stuff in and out of memory in different orders.   DDR
memories like you to take stuff out in the same order you put them
in... they slow down big time when you try to jump around..  So if you
do this, you will need to some up with some clever methods of read out
pieces from DDR in the incorrect order, and then re-reading from a
local, smaller, block ram in the order you actually want.  This will
take careful planning and a lot of simulation, even an experienced
designer would have a tricky time with this and probably get it wrong
in simulation the first shot.

   If your up/down sampling doesn't need to be terribly accurate, this
simplifies things.  Consider a simple first order interpolation...
look left, look right and figure out what goes in between.  You would
do the row dimension as the data flows in, just put two rows into
memory at a time and then do your column dimension.  Obviously, you
will need to calculate bandwidth here and make sure you've got plenty
enough (with margin!) on your memory.

   Also, remember that multiplication & division are tricky in the
binary world.  The spartan3 does have some built in multipliers.  But
for a school project consider limiting your scope to make your life a
little easier.  Maybe you only scale by powers of 2, so everything
becomes a Left/Right shift instead of mult/div?  Maybe you limit it
even more, you take 640x480 60Hz in and you ouptut 1280x960 60Hz, and
do nothing else.  The fewer possible cases you need to accoutn for the
more likely it will be to fit in a smaller part.

  Lastly, are you trying to do this on the spartan3 starter kit?
becuase that has no video in, and only a crude video out (no DAC, you
can just turn on and off the RGB pixels in combinations.. so 2^3 = 8
colors, of which 1 is black and 1 is white)...   If you are building
your own board you are going to be limitted by the size FPGA you can
get in a quad flat pack part - i assume you dont have the facilities
to do a BGA - and those QFPs are still VERY fine pitch to solder by
hand.  Let me know if you've found an eval board already that's
suitable for this application, I;m curious - I don't think any of the
digilent spartan boards have video input.

  Good luck



On May 2, 9:49 pm, "Ken Soon" <c...@xilinx.com> wrote:
> Hi
> Just want to do a feasibility study on whether it is possible to design and
> implement a video scaler on a Spartan 3E?
> Well my tutor kind of came up with this proposal for a project of mine but
> then on my tutor's side, he has experience with fpga but I'm not sure
> whether he had designed video scaling so may not know the complexity of it.
>
> So, feasible? And with which chip as well? (in the best of best case, i hope
> can use just a spartan starter kit :) )



Article: 118785
Subject: Re: Wait-for / until won't work ? Xilinx Spartan 3
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Thu, 3 May 2007 17:17:04 +0100
Links: << >>  << T >>  << A >>

"Paul" <pauljbennett@gmail.com> wrote in message 
news:1178203259.251061.292370@u30g2000hsc.googlegroups.com...
> As far as I've heard/seen in large companies with regulated coding
> styles,
> the wait statement version of a DFF is considered to be sloppy for
> readability maintainability purposes.  tick-event is considered a much
> cleaner way of coding a DFF.

Well, the IEEE rising_edge and falling_edge functions are standard practice 
and for good reason. The 'event syntax is beyond obsolete...

    -Ben- 



Article: 118786
Subject: Re: debounce state diagram FSM - topical
From: "Default User" <defaultuserbr@yahoo.com>
Date: 3 May 2007 16:24:04 GMT
Links: << >>  << T >>  << A >>
CBFalconer wrote:

> What baffles me is that here is a whole list of people complaining,
> and not one of them sets the follow-up marker (except me).  I am
> wondering if there is something in the readers or servers involved.


As I mentioned elsewhere, I don't feel it's appropriate. The only
reason I see to set follow-ups is when attempting to move a thread to a
new group (not in the original distribution).

Setting follow-ups does nothing for where YOUR post appears. If it's
not appropriate for replies to yours to appear in group X, then your
post wasn't appropriate either.

The correct action is to remove group X from your post's distribution.
That's what I did in a couple of early, "please don't post replies to
clc" messages.

These, where we're discussing what I consider to be metatopics, retain
clc (I added it back).





Brian

Article: 118787
Subject: Re: Xilinx software quality - how low can it go ?!
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Thu, 3 May 2007 17:37:10 +0100
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1178205908.643579.42880@o5g2000hsb.googlegroups.com...

> there are NO EXCUSES for bad software.

It depends whether you call it an excuse (emotive) or a reason. Everything 
happens for a reason. Explaining why something happens doesn't equate to 
justification, in my view.

> if there problems are [X], then:
> 1) fix the problems
> 2) seek help
> 3) stop using [X]

That's obvious enough, but it presupposes that you (or one of your 
customers) finds and reports the problem... luckily, we have plenty of 
people like you who are more than happy to bring these things to our 
attention!

Good luck with your remaining issues... :-\

      -Ben- 



Article: 118788
Subject: Use of "blocks" in Quartus design
From: davew <David.Wooff@gmail.com>
Date: 3 May 2007 09:57:28 -0700
Links: << >>  << T >>  << A >>
I'm a fairly experienced user of Quartus but I've never considered
using "blocks" in block design files i.e. my design hierarchy consists
of only symbols with a mixture of Verilog and graphic design modules
"underneath" each symbol.  I have never seen a need to use them.

My question is: does anyone routinely use blocks in their designs and
what are the advantages/disadvantages of doing so?

It seems to me that they must be there for a good reason.  I just
can't see what that reason is and i think I may be missing out on
something potentially useful.

When I say block I mean using the "block" tool not the "symbol" tool.
Blocks are or can be connected together with "conduits" whereas I
think symbols can only be connected with "bus" and "node" connections.


Article: 118789
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 3 May 2007 10:03:10 -0700
Links: << >>  << T >>  << A >>

Ben Jones schrieb:
> "Antti" <Antti.Lukats@xilant.com> wrote in message
> news:1178205908.643579.42880@o5g2000hsb.googlegroups.com...
>
> > there are NO EXCUSES for bad software.
>
> It depends whether you call it an excuse (emotive) or a reason. Everything
> happens for a reason. Explaining why something happens doesn't equate to
> justification, in my view.
>
> > if there problems are [X], then:
> > 1) fix the problems
> > 2) seek help
> > 3) stop using [X]
>
> That's obvious enough, but it presupposes that you (or one of your
> customers) finds and reports the problem... luckily, we have plenty of
> people like you who are more than happy to bring these things to our
> attention!
>
> Good luck with your remaining issues... :-\
>
>       -Ben-

eh, sure different opions. sure.

I really think it would not be so difficult for Xilinx to manage their
software development better
.
(you may have other opinion in this matter)

Antti


Article: 118790
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 3 May 2007 10:21:44 -0700
Links: << >>  << T >>  << A >>

Ben Jones schrieb:
> "Antti" <Antti.Lukats@xilant.com> wrote in message
> news:1178205908.643579.42880@o5g2000hsb.googlegroups.com...
>
> > there are NO EXCUSES for bad software.
>
> It depends whether you call it an excuse (emotive) or a reason. Everything
> happens for a reason. Explaining why something happens doesn't equate to
> justification, in my view.
>
> > if there problems are [X], then:
> > 1) fix the problems
> > 2) seek help
> > 3) stop using [X]
>
> That's obvious enough, but it presupposes that you (or one of your
> customers) finds and reports the problem... luckily, we have plenty of
> people like you who are more than happy to bring these things to our
> attention!
>
> Good luck with your remaining issues... :-\
>
>       -Ben-

HAHAHA!

2 out of 3 EDK installations work now!!! :)

had to copy MAKE.EXE from edk into cygwin dir.

Xilinx should make another AR about this, or adjust the old one about
this issue...

Antti


Article: 118791
Subject: Re: Unused Pin setting on per-pin basis
From: Gabor <gabor@alacron.com>
Date: 3 May 2007 10:28:16 -0700
Links: << >>  << T >>  << A >>
On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote:
> You should be able to alter the UCF to add the pull-up / pull-downs,
> though the resistor is permanently enabled after configuration. (you
> can't control it from the fabric) You can use this feature to
> eliminate external resistors with great effect.  For example, I have a
> small add-in board that doesn't supply a proper VCC, so I use the
> internal pull-up to keep the reset line high, and use a switch to
> short the circuit to ground. Perhaps not the safest circuit, but it
> works.

Again the UCF method only works if the pin in question has
a net attached to it, i.e. if it doesn't get removed from the
project as unused.  I don't know of any method in the UCF
to refer to pins merely by location.  So while you can put a
line in the UCF like
NET "Foo" LOC = AA12 | PULLUP ;
as soon as the net Foo gets removed from the project
the pullup resistor goes away, too.


Article: 118792
Subject: Re: Xilinx WebPACK 91i on vmware RHEL4
From: Stephen Williams <spamtrap@icarus.com>
Date: Thu, 03 May 2007 11:06:46 -0700
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Williams wrote:
> I am trying to install the Xilinx ISE WebPACK software on a vmware
> virtual machine running RHEL4-WS. I made the machine and installed
> RHEL from scratch (it works that far) an now I'm trying to install
> the ISE WebPACK.
> 
> The "setup" program starts up, displays the pretty banner and asks
> me for the devices I want to support. I make my selections, and
> click "Next". The puzzling thing is that the installer thinks there
> are 0 MB available in the destination volume, and asks me if I want
> to install anyhow.
> 
> Has anybody been able to install on a vmware virtual machine? I'm
> trying real hard to give everybody *exactly* what they want, but
> I'm not getting what *I* want:-(

Some progress. I found that the Web install crashes but the single-
file-download works. It still complains that the target fs has 0MB
available (utter nonsense) but it installs anyhow, without crashing.

So the web install is just plain fubar.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGOiS2rPt1Sc2b3ikRAkgjAKDJD2nkVCblCIdC4RFir9ggrq8D7QCfSNX9
m+YmJ0Se0aUy5PqhI2eGZu4=
=cvr4
-----END PGP SIGNATURE-----

Article: 118793
Subject: Re: Unused Pin setting on per-pin basis
From: radarman <jshamlet@gmail.com>
Date: 3 May 2007 11:19:12 -0700
Links: << >>  << T >>  << A >>
On May 3, 12:28 pm, Gabor <g...@alacron.com> wrote:
> On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote:
>
> > You should be able to alter the UCF to add the pull-up / pull-downs,
> > though the resistor is permanently enabled after configuration. (you
> > can't control it from the fabric) You can use this feature to
> > eliminate external resistors with great effect.  For example, I have a
> > small add-in board that doesn't supply a proper VCC, so I use the
> > internal pull-up to keep the reset line high, and use a switch to
> > short the circuit to ground. Perhaps not the safest circuit, but it
> > works.
>
> Again the UCF method only works if the pin in question has
> a net attached to it, i.e. if it doesn't get removed from the
> project as unused.  I don't know of any method in the UCF
> to refer to pins merely by location.  So while you can put a
> line in the UCF like
> NET "Foo" LOC = AA12 | PULLUP ;
> as soon as the net Foo gets removed from the project
> the pullup resistor goes away, too.

If the pin really is unused, and you really want that pin to float or
stay at a DC level, then just add the appropriate net. Even something
simple like dummy_net <= 'Z'; would cover it. Just check the FPGA
editor to make sure you are really getting a permanently disabled tri-
state buffer. Then, add the pullup/pulldown constraint to the UCF. Is
there a reason you can't add a dummy net to the pin?

I generally make a practice of assigning nets to all external I/O, and
then tie them off in the top-level until they are used - just so I can
control stuff like this. That way, I can finish the I/O constraints
early on, and not have to worry about mucking with them later on.


From rich@example.net Thu May 03 11:26:01 2007
Path: nlpi060.nbdc.sbc.com!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!wns13feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc03.POSTED!dd653b87!not-for-mail
From: Rich Grise <rich@example.net>
Subject: Re: debounce state diagram FSM
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table)
Message-Id: <pan.2007.05.03.19.26.38.712172@example.net>
Newsgroups: comp.lang.vhdl,comp.arch.fpga,sci.electronics.design,comp.lang.verilog
References: <1177871564.475673.53180@y80g2000hsf.googlegroups.com> <1178058355.292440.275760@l77g2000hsb.googlegroups.com> <ln647c5aqw.fsf@nuthaus.mib.org> <r2of33htqqttg5d9gmiqcnesfvo0kodcp0@4ax.com> <lnvefc3qst.fsf@nuthaus.mib.org> <pan.2007.05.02.23.31.21.488273@example.net> <59siaaF2k0rjfU1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 20
Date: Thu, 03 May 2007 18:26:01 GMT
NNTP-Posting-Host: 71.103.107.248
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc03 1178216761 71.103.107.248 (Thu, 03 May 2007 14:26:01 EDT)
NNTP-Posting-Date: Thu, 03 May 2007 14:26:01 EDT
Xref: prodigy.net comp.lang.vhdl:69944 comp.arch.fpga:130470 sci.electronics.design:802932 comp.lang.verilog:36043
X-Received-Date: Thu, 03 May 2007 14:26:02 EDT (nlpi060.nbdc.sbc.com)

On Wed, 02 May 2007 22:40:10 +0000, Default User wrote:

> Rich Grise wrote:
> 
> 
>> Well, you could have removed comp.lang.c from your own followups,
>> rather than perpetuating it. After all, you only want to bitch at the
>> people in the other groups, right?
>> 
>> And you do know how to set "followups-to", don't you?
> 
> People keep saying this like it's some sort of magic. All that does
> direct replies to THAT message to certain groups. It has jack to do
> with the thread.

Then change the "Newsgroups" field, like I've done with this post.

Good Luck!
Rich


Article: 118794
Subject: Re: fast arbiters (was Re: How to design an abitration cicuit...)
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Thu, 3 May 2007 18:41:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1178200419.714442.227530@l77g2000hsb.googlegroups.com>,
romi  <weberrm@gmail.com> wrote:
>On May 2, 9:11 am, jhal...@TheWorld.com (Joseph H Allen) wrote:
>> // Concise priority arbiter
>> input [26:0] req; // Bit zero is highest priority
>> wire [26:0] gnt = req & -req; // Isolate least significant set bit

>> reg [26:0] prev; // Previous winner (saved from last cycle)
>> wire [26:0] req1 = req & ~((prev - 1) | prev); // Mask off previous winners
>> wire [26:0] gnt1 = req1 & -req1; // Select new winner
>> wire [26:0] winner = |gnt1 ? gnt1 : gnt; // Start from bit zero if none

>> // Save previous winner
>> always @(posedge clk) if (winner) prev <= winner;

>Since gnt1 implies that there was a req1, wouldn't it be better
>(faster) to use req1 in the winner selection?

>wire [26:0] winner = |req1 ? gnt1 : gnt; // Start from bit zero if
>none

Yes. Cool. :-)

Here are some other variations:

If the carry chain is really fast, get rid of the mux:

wire [53:0] req1 = { req, req & ~((prev - 1) | prev) };
wire [53:0] gnt1 = req1 & -req1;
wire [26:0] winner = gnt1[53:27] | gnt1[26:0];

Or use wrap-around carry, if you don't mind the combinatorial loop:

// Rotate previous winner one bit to the left.  If no previous winner,
// pretend it was prev[26].
wire [26:0] prev1 = |prev ? { prev[25:0], prev[26] } : 27'd1;

// Wrap-around two's complement where the add 1 is just to the left of the
// previous winner instead of at bit 0.
wire [27:0] tmp = { 1'b0, ~req } + ({ 1'b0, prev1 } | { 27'b0, tmp[27] });

wire winner = req & tmp[26:0];

This is probably the fastest, but you need a synthesis tool which allows
combinatorial loops.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 118795
Subject: Re: debounce state diagram FSM
From: Flash Gordon <spam@flash-gordon.me.uk>
Date: Thu, 03 May 2007 20:23:11 +0100
Links: << >>  << T >>  << A >>
Rich Grise wrote, On 03/05/07 19:36:
> On Thu, 03 May 2007 00:13:04 +0100, Flash Gordon wrote:
> 
>> Rich Grise wrote, On 02/05/07 23:41:
>>> On Wed, 02 May 2007 08:02:40 +0100, Flash Gordon wrote:
>>>
>>>> Note I've not set followups this time because discussions about 
>>>> topicality *are* topical.
>>> And you're still following up to the group that you want the crosspost
>>> removed from.
>>>
>>> Are you C people all that lame?
>>>
>>> Here's a clue: Set your followups to:
>>> comp.lang.vhdl,comp.arch.fpga,sci.electronics.design,comp.lang.verilog
>>> for your whining and bellyaching - you might be surprised!
>> That does sod all good because the off topic posts are not in response 
>> to it being redirected.
> 
> So, change the "Newsgroups" field in the post that you're actually
> posting, and to hell with the followups!
> 
> See what I've done here? Look at my headers. See? No crosspost.

That still does sod all good for the reason stated above. Restringing 
where MY post goes, or where follow ups to it go, does NOT affect where 
other messages go.

> I also had to put that in by hand, since your "followups to" did,
> in fact, default to everything but comp.lang.c - you simply have
> to be smarter than your newsreader.

No, it did not default, it was explicitly changed. I know EXACTLY how to 
use my news reader.

> Sheesh!

Try reading what was written.
-- 
Flash Gordon

Article: 118796
Subject: Re: Wait-for / until won't work ? Xilinx Spartan 3
From: Paul <pauljbennett@gmail.com>
Date: 3 May 2007 12:53:22 -0700
Links: << >>  << T >>  << A >>
Rising_edge / Falling edge only matter if you're using non '0' / '1'
values in your simulation...  U -> '1' is not a rising edge with
"rising_edge" but is a rising edge if you use 'EVENT.  But U, H, X, L,
etc... only exist in simulation, no such thing inside your FPGA, so
assuming you setup your simulation to reflect reality there's no
difference.



On May 3, 12:17 pm, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> "Paul" <pauljbenn...@gmail.com> wrote in message
>
> news:1178203259.251061.292370@u30g2000hsc.googlegroups.com...
>
> > As far as I've heard/seen in large companies with regulated coding
> > styles,
> > the wait statement version of a DFF is considered to be sloppy for
> > readability maintainability purposes.  tick-event is considered a much
> > cleaner way of coding a DFF.
>
> Well, the IEEE rising_edge and falling_edge functions are standard practice
> and for good reason. The 'event syntax is beyond obsolete...
>
>     -Ben-



Article: 118797
Subject: Select pullup, pulldown or none via embedded S/W
From: moogyd@yahoo.co.uk
Date: 3 May 2007 13:11:19 -0700
Links: << >>  << T >>  << A >>
Hi,
Within our ASIC library, we have an I/O pad which has input pins
allowing us to select whether a pullup, pulldown or none is enabled
for this pad.
This is very useful for GPIO.

We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform,
and we would like the same functionality.

Is this possible ?

Thanks,

Steven


Article: 118798
Subject: Re: Select pullup, pulldown or none via embedded S/W
From: austin <austin@xilinx.com>
Date: Thu, 03 May 2007 13:37:48 -0700
Links: << >>  << T >>  << A >>
Steven,

http://direct.xilinx.com/bvdocs/userguides/ug331.pdf

page 311.

Yes.

Austin

Article: 118799
Subject: Re: Select pullup, pulldown or none via embedded S/W
From: Antti <Antti.Lukats@xilant.com>
Date: 3 May 2007 13:41:34 -0700
Links: << >>  << T >>  << A >>
moogyd@yahoo.co.uk schrieb:
> Hi,
> Within our ASIC library, we have an I/O pad which has input pins
> allowing us to select whether a pullup, pulldown or none is enabled
> for this pad.
> This is very useful for GPIO.
>
> We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform,
> and we would like the same functionality.
>
> Is this possible ?
>
> Thanks,
>
> Steven

only if you have device that has ICAP or then you route JTAG to GPIO
and is not easy, need to modify the actual configuration

Antti




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