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 134875

Article: 134875
Subject: Re: EDK frequency problem
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 04 Sep 2008 08:14:22 -0700
Links: << >>  << T >>  << A >>
fmostafa wrote:

> is there
> anything else i have to change

Since it doesn't work, the answer is yes.
I would check the static timing
for Fmax > 66MHz as a start.

  -- Mike Treseler

Article: 134876
Subject: Spartan-3 -> Spartan-2 problem
From: aleksa <aleksaZR@gmail.com>
Date: Thu, 4 Sep 2008 08:34:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
About two months ago I've started learning VHDL, CPLD and FPGA.

Right from the start I've choosen Spartan-3 (XC3S50) and
didn't look at Spartan-II because I wanted to use the latest chip.

Now I am making a board with 50 5V TTL inputs and idea was to use
the CPLD XC95144XL as a level translator...but I just don't like it.

So, now I am trying Spartan-II (XC2S50),
which is 5V tolerant, and I have 3 problems/issues:

1. when I start "Implement design", ISE complains:
   "MapLib:95 - IBUF symbol "CLOCK1_IBUF" (output signal=CLOCK1_IBUF1)
    is promoted to indicate the use of GCLKIOB site."

   I have 7 clocks in my design and ISE gives me the same report
   for 3 of them. What does it mean and what should I do about it?

   It works fine on spartan-3.


2. when I start "Floorplan IO - Pre-Synthesis", ISE complains:
   "ERROR:HDLParsers:3562 - pepExtractor.prj line 1
    Expecting 'vhdl' or 'verilog'   keyword,  found 'work'."

   (This I can fix with LOC attribute..)


3. for how long will	 Spartan-II be available?


Cheers

Article: 134877
Subject: Re: Strange Spartan2 behaviour
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 04 Sep 2008 16:06:03 GMT
Links: << >>  << T >>  << A >>
Jochen <JFrensch@harmanbecker.com> wrote:

>We had an issue with a "ground bounce" (Spartan3 design) in the bank
>containing the PCI-interface, which 'triggered' the asynchonous reset
>of the PCI-core...
>
>Do you use async resets ?

Yes. The design uses async resets. But it doesn't seem to affect the
PCI core. The problem is always in the part with the statemachines.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 134878
Subject: Re: Strange Spartan2 behaviour
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 04 Sep 2008 16:15:19 GMT
Links: << >>  << T >>  << A >>
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:

>On Wed, 03 Sep 2008 22:33:14 GMT, nico@puntnl.niks (Nico Coesel)
>wrote:
>
>>In some specific type of PCs (mostly server chassis) the design quits
>>working right away or after a while. Some of the internal
>>statemachines quit even when the option 'Safe implementation' is
>>turned on. In most PCs (say 99.9%) the design works okay though. 
>
>Random data point from the mediaeval era:  I had almost identical
>symptoms with a video processing card, about 15 years ago, in 
>ISA bus.  I eventually tracked it down to glitches on the bus 
>reset line, so narrow that all the old-style ISA cards missed
>it, but the fast-ish FPGAs on my board would sometimes see it.
>
>I don't suppose it's the same issue for you.  But it's weird
>how this kind of thing rears its head from time to time.

Thanks, this sounds interesting. 

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 134879
Subject: Re: Inferring dual-port RAM in Spartan-3A Starter Kit FPGA?
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 04 Sep 2008 09:53:22 -0700
Links: << >>  << T >>  << A >>
Brian Drummond wrote:

> But it's only worth pushing on that rope for so long. Then concede
> defeat; save time and instantiate the primitive component directly.

Or use the portable template with one read and one write port.

        -- Mike Treseler

Article: 134880
Subject: Re: Strange Spartan2 behaviour
From: Ben Jackson <ben@ben.com>
Date: Thu, 04 Sep 2008 17:32:56 GMT
Links: << >>  << T >>  << A >>
On 2008-09-03, Nico Coesel <nico@puntnl.niks> wrote:
>
> In some specific type of PCs (mostly server chassis) the design quits
> working right away or after a while.

Many desktop-class systems don't check PCI parity at all.  Maybe that's
changing as logic gets cheaper, but I know I implemented a target that
didn't output any parity at all which worked fine on the motherboards I
had at home.

It's possible that your "server" motherboards are checking parity, seeing
an error and doing something that you did not anticipate with your state
machine.

Of course with your PCI-PCIe bridge the problem should be isolated from the
motherboard, but I can't tell if it was involved when you saw the problem.

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

Article: 134881
Subject: Re: Strange Spartan2 behaviour
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 04 Sep 2008 19:47:28 GMT
Links: << >>  << T >>  << A >>
Ben Jackson <ben@ben.com> wrote:

>On 2008-09-03, Nico Coesel <nico@puntnl.niks> wrote:
>>
>> In some specific type of PCs (mostly server chassis) the design quits
>> working right away or after a while.
>
>Many desktop-class systems don't check PCI parity at all.  Maybe that's
>changing as logic gets cheaper, but I know I implemented a target that
>didn't output any parity at all which worked fine on the motherboards I
>had at home.
>
>It's possible that your "server" motherboards are checking parity, seeing
>an error and doing something that you did not anticipate with your state
>machine.
>
>Of course with your PCI-PCIe bridge the problem should be isolated from the
>motherboard, but I can't tell if it was involved when you saw the problem.

Well, the PCI core is behaving just fine. It is the 'PCI client' side
which goes wrong in a particular area which has nothing to do with the
PCI core directly. But I guess it doesn't hurt to put a counter on the
PERR signal to make sure. Thanks for the hint.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 134882
Subject: Re: Inferring dual-port RAM in Spartan-3A Starter Kit FPGA?
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 4 Sep 2008 13:37:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 4, 9:53=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> Brian Drummond wrote:
> > But it's only worth pushing on that rope for so long. Then concede
> > defeat; save time and instantiate the primitive component directly.
>
> Or use the portable template with one read and one write port.
>
> =A0 =A0 =A0 =A0 -- Mike Treseler

...but the need was for 2 write ports (and 2 associated read ports): a
true dual-port RAM

Article: 134883
Subject: uClinux / Microblaze -- Min. Requirements
From: benn <benn686@hotmail.com>
Date: Thu, 4 Sep 2008 14:05:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm looking into running uClinux on a Microblaze.. and I read that
Microblaze alone uses up about 900 logic cells...  not sure how many
gates that equates to, but anyone venture a guess if a Spartan II
(150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux?


Article: 134884
Subject: Re: Inferring dual-port RAM in Spartan-3A Starter Kit FPGA?
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 04 Sep 2008 14:11:17 -0700
Links: << >>  << T >>  << A >>
John_H wrote:

> ...but the need was for 2 write ports (and 2 associated read ports): a
> true dual-port RAM


I would make an arbiter
to interleave the accesses on alternate cycles,
or redo the design to use a fifo.
There is no other portable way to infer
a full dpram.



         -- Mike Treseler

Article: 134885
Subject: Re: XST bug on illigal states of a FSM ?
From: Andy <jonesandy@comcast.net>
Date: Thu, 4 Sep 2008 15:09:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm not sure that defining a safe state machine is always a good
option. For example, what if he had designed his FSM to be safe, and
that ended up hiding the fact that he was not properly handling
initialization timing (reset vs configuration is moot in this respect;
both have to be timed properly)? Perhaps during development, safe
techniques should be turned off, such that the rest of the design can
be tested, then turned back on for final test and production if
needed.

I learned the hard way, on my very first design, the hazards of not
properly handling asynchronous inputs to state machines. In those days
(PALs), we defined the binary state assignments on K-maps and ensured
that destinations of transitions due to asynchronous inputs were
always adjacent (single bit change). Given the scarcity of registers,
this was the most efficient way to handle asynchronous inputs.
Unfortunately with one-hot encodings, there are no adjacent states.

Andy




Article: 134886
Subject: Re: Open source licenses for hardware
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Thu, 4 Sep 2008 17:55:30 -0500
Links: << >>  << T >>  << A >>
"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:48bf9105$0$25395$8404b019@news.wineasy.se...
> Jon Beniston wrote:
>>>  The choice of the GPL
>>> for the OpenSparc is similar - it effectively restricts its use to
>>> evaluation and academic work
>>
>> Not if they used the LGPL, it isn't.
>>
>
> They use the GPLv2, not the LGPL.
>
> One other point that I did not mention earlier for both GPL'ed code and 
> LGPL'ed code is that it is perfectly possible to make and sell devices 
> that use GPL'ed IP - as long as *all* the IP in the device is GPL'ed.

GPL, or equivalent license. The only requirement is the end user can build 
the system without paying someone for licenses.

>
> I think it is very reasonable to say that the bitstream for a single FPGA 
> device is a single "work", and that the license for that "work" is not 
> affected by the licenses of any other "work", including other FPGA designs 
> and software running on the FPGA, at least as long as you are talking 
> about a complete design with a specific interface.

The GPL specifically excludes "mere aggregation ... on a volume of a storage 
or distribution medium" from consideration. But you don't have to fight that 
battle to determine reasonable use. The bitstream is a distribution medium. 
However, that alone does not release the conveyor from the GPL's terms.

The real issue is conveying the work if the end user cannot examine the 
work, modify it, and build it into a working system. The presence of other 
licensed IPs precludes distributing the modified work. He would have to 
license the other IPs in order to build and distribute the system. This is 
relevant in manufacturing scenarios, where the "work" is typically 
incorporated into the ROM of the presumably commercial hardware product. The 
issue is not the distribution medium, but licensing terms for the other, 
more restrictive IPs.

This has no consequence for the single user. He may freely compile the 
GPL'ed source into his own work, if he is otherwise able to do so. (Hmmm. 
The EDK is not free. Microblaze and MPMC are licensed for use with the EDK. 
Is this an issue for GPL terms? I think not, but that can be a discussion 
point.)

Anyway... Genode specifically makes the distinction between open source and 
commercial use in their license terms. The bitstream aspect is not a special 
case for GPL, and does not introduce new difficulties. Genode's stated 
intent was that you may examine the work, extend it as you wish, and convey 
the changes if you like as an open source work. They address commercial 
licensing terms separately. LGPL is not suitable for their intents. By 
releasing under LGPL, they essentially relinquish their commercial rights, 
which they expressly wish to hold.



Article: 134887
Subject: Re: Genode FPGA graphics project launched
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 04 Sep 2008 15:51:40 -0800
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:

(snip)
> The work can't be only part of the bitstream,
 > because the parts can't be seperated easily.
 > The IP inside a bitstream has a much tighter coupling
> than statically linked code has.

I am not so sure.  Maybe logically, but not necessarily
legally.  With some amount of work, you might be able
to generate a bitstream not containing certain parts
of the logic, and a bitstream that could be combined
with it that would generate the final result.

That might require more details of the bitstream
than are normally available, but that doesn't mean
it can't be done as far as the legal system is
concerned.

-- glen


Article: 134888
Subject: Re: crazy patent
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 04 Sep 2008 16:03:59 -0800
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> langwadt@fonz.dk wrote:

>> http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet

>> http://www.patentstorm.us/patents/7391237/description.html

> Patents often clearly fail many of the thresholds they are supposed to 
> pass, in part because the filing lawyers are motivated by the payment
> and act of creating a patent. It is not helped either, that most
> lawyers have no idea, or experience, of the item-field.
> A patent is merely a license to litigate,

It sounds somewhat like what motherboard designers with
flash upgrade must also do, though the details will be
different in each case.

It seems likely that the patent makes sense for some
particular case, but was written and approved more generally
than it should have been.

-- glen


Article: 134889
Subject: Re: icap Xwicap_DeviceRead problems
From: lixia.rem@gmail.com
Date: Thu, 4 Sep 2008 18:51:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 7=D4=C223=C8=D5, =CF=C2=CE=E74=CA=B134=B7=D6, lixia....@gmail.com wrote:
> hi all,
> I'm trying to partially reconfigure my device (XC2VP30 on XUP board)
> through ICAP. I have my
>
> ICAP attached to OPB which is attached to MicroBlaze.In bitgen.ut file
> I have set the value of mode pins (M2M1M0) to 1 (PULLUP). So it is not
> set on 101 which is JTAG mode. The value of persist is NO.Initially my
> OPB clock frequency is 25MHz .The system contains  a hwicap, a
> uartlite and mdm all attached to the opb. . I'm using EDK9.1.
>
> i tried to start with an exmaple xhwicap_srp_example.c, but even the
> part of initialize can't go through;when using  XHI_XC2VP30 instead of
> HWICAP_DEVICEID ,the initialize seems success,but the return of
> Xhwicap_DeviceRead() is "device is busy",so the following function
> can't execute.In other word,the deviceread of icap can't sucess,and it
> leads to device busy and the program hangs.
>
> Besides,i find out that the program hangs on the setting of RNC
> register in the Xhwicap_DeviceWrite() function,but the size and offset
> regiser can be set successfully,
> I don't get what the problem is.
>
> In bitgen.ut file I have set the value of mode pins (M2M1M0) to 1
> (PULLUP). So it is not set on 101 which is JTAG mode,and perisit is
> set to No.And on the borad ,the config mode controlled by sw9 is not
> JTAG too.
>
> i don't know if there is something else need to be noticed?
>
>  I really appreciate it if you could kindly help me out with it.
>
> Thanks a lot beforehand,
>
> lixia

my problem is solved when i choose v1_00_b for the ip and v1_00_a for
the driver.
thank you for fatmas' reply!


Article: 134890
Subject: Re: icap Xwicap_DeviceRead problems
From: lixia.rem@gmail.com
Date: Thu, 4 Sep 2008 18:53:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 7=D4=C223=C8=D5, =CF=C2=CE=E74=CA=B134=B7=D6, lixia....@gmail.com wrote:
> hi all,
> I'm trying to partially reconfigure my device (XC2VP30 on XUP board)
> through ICAP. I have my
>
> ICAP attached to OPB which is attached to MicroBlaze.In bitgen.ut file
> I have set the value of mode pins (M2M1M0) to 1 (PULLUP). So it is not
> set on 101 which is JTAG mode. The value of persist is NO.Initially my
> OPB clock frequency is 25MHz .The system contains  a hwicap, a
> uartlite and mdm all attached to the opb. . I'm using EDK9.1.
>
> i tried to start with an exmaple xhwicap_srp_example.c, but even the
> part of initialize can't go through;when using  XHI_XC2VP30 instead of
> HWICAP_DEVICEID ,the initialize seems success,but the return of
> Xhwicap_DeviceRead() is "device is busy",so the following function
> can't execute.In other word,the deviceread of icap can't sucess,and it
> leads to device busy and the program hangs.
>
> Besides,i find out that the program hangs on the setting of RNC
> register in the Xhwicap_DeviceWrite() function,but the size and offset
> regiser can be set successfully,
> I don't get what the problem is.
>
> In bitgen.ut file I have set the value of mode pins (M2M1M0) to 1
> (PULLUP). So it is not set on 101 which is JTAG mode,and perisit is
> set to No.And on the borad ,the config mode controlled by sw9 is not
> JTAG too.
>
> i don't know if there is something else need to be noticed?
>
>  I really appreciate it if you could kindly help me out with it.
>
> Thanks a lot beforehand,
>
> lixia

my problem is solved when i choose v1_00_b for the ip and v1_00_a for
the driver.
thank you for fatma's reply!




Article: 134891
Subject: Re: uClinux / Microblaze -- Min. Requirements
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 4 Sep 2008 21:33:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 sept, 00:05, benn <benn...@hotmail.com> wrote:
> I'm looking into running uClinux on a Microblaze.. and I read that
> Microblaze alone uses up about 900 logic cells... =A0not sure how many
> gates that equates to, but anyone venture a guess if a Spartan II
> (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux?

requirements (absolute minimal)
MB-uClinux
*microblaze
*intc
*timer
*uartlite
* 4M RAM (maybe 2 or even 1)

MB + small (minimal) system does fit s2-150
but 16MB sounds like SDRAM so you need sdram controller ip as well
if that together fits s2-150 i bet it is gonna be very tight

Antti





Article: 134892
Subject: Re: Open source licenses for hardware
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 05 Sep 2008 09:20:11 +0200
Links: << >>  << T >>  << A >>
MikeWhy wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message 
> news:48bf9105$0$25395$8404b019@news.wineasy.se...
>> Jon Beniston wrote:
>>>>  The choice of the GPL
>>>> for the OpenSparc is similar - it effectively restricts its use to
>>>> evaluation and academic work
>>>
>>> Not if they used the LGPL, it isn't.
>>>
>>
>> They use the GPLv2, not the LGPL.
>>
>> One other point that I did not mention earlier for both GPL'ed code 
>> and LGPL'ed code is that it is perfectly possible to make and sell 
>> devices that use GPL'ed IP - as long as *all* the IP in the device is 
>> GPL'ed.
> 
> GPL, or equivalent license. The only requirement is the end user can 
> build the system without paying someone for licenses.
> 

I don't think the GPL allows for mixing GPL code with "equivalent" 
licenses, although it is certainly possible (and not uncommon) to mix it 
with code that is dual licensed so that you are allowed to treat the 
code as pure GPL (the LGPL, for example, explicitly allows that). 
However, that's perhaps nitpicking.  The point is, as you said, that the 
end user can view, modify, rebuild and distribute the code without other 
licenses (although they may have to pay a small handling fee to get the 
source code, and may have to pay for the tools).

>>
>> I think it is very reasonable to say that the bitstream for a single 
>> FPGA device is a single "work", and that the license for that "work" 
>> is not affected by the licenses of any other "work", including other 
>> FPGA designs and software running on the FPGA, at least as long as you 
>> are talking about a complete design with a specific interface.
> 
> The GPL specifically excludes "mere aggregation ... on a volume of a 
> storage or distribution medium" from consideration. But you don't have 
> to fight that battle to determine reasonable use. The bitstream is a 
> distribution medium. However, that alone does not release the conveyor 
> from the GPL's terms.
> 

The bitstream is not just the "distribution medium" - it is also the 
"program".  It is the equivalent of the elf or exe file as well.  (If 
you have code for two or more FPGA's in the same bitstream, then these 
are obviously "mere aggregates".)  To be aggregates, you must be able to 
separate the parts, use them separately, and replace them separately.

> The real issue is conveying the work if the end user cannot examine the 
> work, modify it, and build it into a working system. The presence of 
> other licensed IPs precludes distributing the modified work. He would 
> have to license the other IPs in order to build and distribute the 
> system. This is relevant in manufacturing scenarios, where the "work" is 
> typically incorporated into the ROM of the presumably commercial 
> hardware product. The issue is not the distribution medium, but 
> licensing terms for the other, more restrictive IPs.
> 

That's certainly a major issue, yes.

> This has no consequence for the single user. He may freely compile the 
> GPL'ed source into his own work, if he is otherwise able to do so. 
> (Hmmm. The EDK is not free. Microblaze and MPMC are licensed for use 
> with the EDK. Is this an issue for GPL terms? I think not, but that can 
> be a discussion point.)
> 

IP and code that comes with the standard Xilinx tools will count as 
"standard system libraries", and can be freely used with GPL'ed code in 
the same way as software on Windows uses the windows headers, or 
software written in Python uses the Python libraries (which are not 
GPL'ed, but have their own open source license).  Whether or not the 
Microblaze is a "standard system library" could certainly be discussed.

It's that sort of thing that makes it so important to have an informal 
but clear "clarification statement" along with a license.  For example, 
Linux has a statement making it perfectly clear that programs that use 
the Linux API are in no way "derived works", and are unaffected by the 
GPL in the kernel (there is no such statement surrounding binary 
drivers, and thus plenty of discussion there!).

> Anyway... Genode specifically makes the distinction between open source 
> and commercial use in their license terms. The bitstream aspect is not a 
> special case for GPL, and does not introduce new difficulties. Genode's 
> stated intent was that you may examine the work, extend it as you wish, 
> and convey the changes if you like as an open source work. They address 
> commercial licensing terms separately. LGPL is not suitable for their 
> intents. By releasing under LGPL, they essentially relinquish their 
> commercial rights, which they expressly wish to hold.
> 

Yes, I think the full GPL is the correct choice for Genode in this case, 
although as I said before I don't think the LGPL would be any different 
legally.  However, since the LGPL is in many ways harder to understand 
(look at this thread here), the full GPL is a better choice here.


Article: 134893
Subject: Re: Quartus II priority 19 under Linux
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 05 Sep 2008 09:23:54 +0200
Links: << >>  << T >>  << A >>
H. Peter Anvin wrote:
> David Brown wrote:
>> Petter Gustad wrote:
>>> Why does Quartus run with lowest priority level (19) under Linux? It
>>> also seems like if you nice quartus_sh to some higher priority when
>>> you start it the sub-processes (like qartus_map etc) will still have
>>> priority 19. I find this a little odd. Is there a reason for this?
>>>
>>
>> I'd imagine the idea is that you can continue working with other 
>> programs while the long-running processes run in the background.  
>> Modern Linux kernels typically have schedulers that automate this 
>> (giving higher priority to short-running interactive processes), but 
>> there is no harm in running something like Quartus at low priority 
>> unless you are simultaneously running another process that tries to 
>> use all available processing time.
> 
> It really hurts you if you have server machines with "cycle-scraper" 
> processes (often verification jobs) that administratively have lower 
> priority than Quartus.
> 
> You want to be able to control this behaviour.
> 

Yes, you should be able to control it - as you say, you may have several 
low-priority jobs that you want done in the background, and some are 
lower priority than others.  I'd imagine that Altera have been thinking 
mainly of the common case running on an engineer's workstation rather 
than a server, but they could still have been more flexible.

Of course, you could always get a multi-core cpu for your server - these 
jobs are seldom multi-threaded, so that would let you do both at once.

Article: 134894
Subject: Re: Quartus II priority 19 under Linux
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Fri, 05 Sep 2008 09:56:09 +0200
Links: << >>  << T >>  << A >>
David Brown <david@westcontrol.removethisbit.com> writes:

> some are lower priority than others.  I'd imagine that Altera have
> been thinking mainly of the common case running on an engineer's
> workstation rather than a server, but they could still have been more
> flexible.

Altera is still into the mindset of one engineer working on one FPGA
on his or hers PC. 

> Of course, you could always get a multi-core cpu for your server -
> these jobs are seldom multi-threaded, so that would let you do both at
> once.

grep -c ^processor  /proc/cpuinfo
8

:-)

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 134895
Subject: Re: Hide VHDL code.
From: Pablo <pbantunez@gmail.com>
Date: Fri, 5 Sep 2008 01:12:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 4, 2:36=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 4 Sep 2008 02:24:50 -0700 (PDT), Pablo <pbantu...@gmail.com>
> wrote:
>
> >I am trying to use XST to create a "black box" from a VHDL core. The
> >output NGC file fails when I try to include it in a Xilinx ISE design.
> >Does anyone know the way to create a black box from a file.vhd?
>
> >best regards.
>
> First thing to check is that the output NGC file was synthesised without
> I/O buffers on its internal ports. There are synthesis options for this.
>
> That would certainly cause it to fail when included in another design...
>
> - Brian

ok. Thanks Brian.

Article: 134896
Subject: Re: uClinux / Microblaze -- Min. Requirements
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Sep 2008 05:53:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 4, 5:05=A0pm, benn <benn...@hotmail.com> wrote:
> I'm looking into running uClinux on a Microblaze.. and I read that
> Microblaze alone uses up about 900 logic cells... =A0not sure how many
> gates that equates to, but anyone venture a guess if a Spartan II
> (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux?

If you know how many logic cells the Microblaze uses, why don't you
just look at how many logic cells your FPGAs have???  Gate count is a
level removed from reality both in the design and in the chip.  So why
translate into the domain of a poor measurement?

Rick

Article: 134897
Subject: Re: uClinux / Microblaze -- Min. Requirements
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 5 Sep 2008 06:56:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 5 sept, 15:53, rickman <gnu...@gmail.com> wrote:
> On Sep 4, 5:05=A0pm, benn <benn...@hotmail.com> wrote:
>
> > I'm looking into running uClinux on a Microblaze.. and I read that
> > Microblaze alone uses up about 900 logic cells... =A0not sure how many
> > gates that equates to, but anyone venture a guess if a Spartan II
> > (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux?
>
> If you know how many logic cells the Microblaze uses, why don't you
> just look at how many logic cells your FPGAs have??? =A0Gate count is a
> level removed from reality both in the design and in the chip. =A0So why
> translate into the domain of a poor measurement?
>
> Rick

the gate count is sure ir relevant
but the MB LC count is also :)

he needs to build the system and check it out
and change options to optimize
this can not be calculated from datasheets

Antti



Article: 134898
Subject: Re: XST bug on illigal states of a FSM ?
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 5 Sep 2008 07:02:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 3, 3:43=A0pm, Kevin Neilson <kevin_neil...@removethiscomcast.net>
wrote:

> Here's an example. =A0These two counters operate in the same way:
>
> reg [7:0] count1=3D0, count2=3D0;
> always@(posedge clk)
> =A0 =A0begin
> =A0 =A0 =A0if (count1=3D=3D135) count1 <=3D 0;
> =A0 =A0 =A0else count1 <=3D count1 + 1;
> =A0 =A0 =A0if (count2>134) count2 <=3D 0;
> =A0 =A0 =A0else count2 <=3D count2 + 1;
> =A0 =A0end
>
> You can see that both counters are identical, but if synthesized
> according to the RTL, count2 will have a lot more logic and will be
> slower, because the > with synthesize a subtractor. =A0But it's just a
> waste of logic, because count2 will never have a value of 136 or
> greater

It's interesting when people forget the fundamental principles that
underly an implementation (in this case simple boolean logic) and/or
the hardware assist that may or not be available in a particular
device and then make claims that don't stand up.

The only way count2 would have a lot more logic as you say would be if
the targetted device had a hardware implementation of an equality
comparator but had to implement 'greater than' with logic.

Without such a hardware assist though, count2 will always synthesize
to either the same amount of logic or somewhat less logic than that
needed for count1 (usually it will be slightly less).  Given a
programmable device that has to implement both ">" and "=3D" in logic,
all synthesis tools will eventually map these into the fundamental
boolean logic that describes this and optimize the implementation of
those equations.  Using ">" allows for more optimizations since those
unreachable count values are then used to implement different boolean
equations to define the input to the flops that are less specific than
the one particular case being singled out for "=3D".

In any case, count1 and count2 should result in basically the exact
same amount of logic resources and performance.  If not, then your
synthesis tool likely has a problem.  Some example VHDL code is shown
below which describes the two different methods that you mentioned as
well as a third method which uses integers defined over the valid
counting range.  Fitter results are in the comments.  Using an integer
resulted in the same logic usage as ">"; logic resource usage for ">"
was always better than that for "=3D" (but not by much).

Take the example code I've provided out for a spin (or even the code
that you posted above) target some actual devices and see for yourself
that it doesn't much matter.

Kevin Jennings
**** Start of code ****
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Cnt1 is
generic(
    Bits:   positive :=3D 24;
    Max:    positive :=3D 2**23+ 135);
port(
    ------------------------------------------------
    -- Targetting a Cyclone II, Cnt1 synthesizes to:
    -- Params                   Logic elements
    -- =3D=3D=3D=3D=3D=3D                   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
    -- Bits=3D8,  Max=3D135         12
    -- Bits=3D24, Max=3D135         33
    -- Bits=3D24, Max=3D2**23+135   34
    ------------------------------------------------
    clk:    in  std_logic;
    count:  out std_logic_vector((Bits - 1) downto 0));
end Cnt1;
architecture RTL of Cnt1 is
    signal count_int:   unsigned(count'range)   :=3D (others =3D> '0');
begin
    process(clk)
    begin
        if rising_edge(clk) then
            if (count_int =3D Max) then
                count_int <=3D to_unsigned(0, count_int'length);
            else
                count_int <=3D count_int + 1;
            end if;
        end if;
    end process;
    count <=3D std_logic_vector(count_int);
end RTL;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Cnt2 is
generic(
    Bits:   positive :=3D 24;
    Max:    positive :=3D 2**23+ 135);
port(
    ------------------------------------------------
    -- Targetting a Cyclone II, Cnt2 synthesizes to:
    -- Params                   Logic elements
    -- =3D=3D=3D=3D=3D=3D                   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
    -- Bits=3D8,  Max=3D135         11
    -- Bits=3D24, Max=3D135         32
    -- Bits=3D24, Max=3D2**23+135   32
    ------------------------------------------------
    clk:    in  std_logic;
    count:  out std_logic_vector((Bits - 1) downto 0));
end Cnt2;
architecture RTL of Cnt2 is
    signal count_int:   unsigned(count'range)   :=3D (others =3D> '0');
begin
    process(clk)
    begin
        if rising_edge(clk) then
            if (count_int > (Max - 1)) then
                count_int <=3D to_unsigned(0, count_int'length);
            else
                count_int <=3D count_int + 1;
            end if;
        end if;
    end process;
    count <=3D std_logic_vector(count_int);
end RTL;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Cnt3 is
generic(
    Max:    positive :=3D 2**23+ 135);
port(
    ------------------------------------------------
    -- Targetting a Cyclone II, Cnt3 synthesizes to:
    -- Params                   Logic elements
    -- =3D=3D=3D=3D=3D=3D                   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
    -- Max=3D135                  11
    -- Max=3D2**23+135            32
    ------------------------------------------------
    clk:    in  std_logic;
    count:  out natural range 0 to Max);
end Cnt3;
architecture RTL of Cnt3 is
    signal count_int:   natural range 0 to Max   :=3D 0;
begin
    process(clk)
    begin
        if rising_edge(clk) then
            if (count_int > (Max - 1)) then
                count_int <=3D 0;
            else
                count_int <=3D count_int + 1;
            end if;
        end if;
    end process;
    count <=3D count_int;
end RTL;
**** End of code ****

Article: 134899
Subject: Re: encryption
From: amigo65@gmail.com
Date: Fri, 5 Sep 2008 07:52:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi
i want some help
i m in my final year of avionics engg
i have been give a project to develop a fpga based encryption module
for voice comunication
can u help me in it

yusufil...@gmail.com wrote:
> hi,
>
> I would like to implement a secure channel over an unsecure medium.
>
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
>
> I do not want to encrypt data at the device's digital side
> because it is unsecure, and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.
>
> What I want to do is ;
>
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal
>
> The Device will see voice freq signal and will transmit them through
> channel as if they are real voices.
> At this point adding some noise may help a lot.
> a little bit noise may fool attackers but human still can understand
> what is said.
>
>
> questions:
>
> what is possible weakness of this system?
> I am sure it can be still broken but
> how easy to break it?
> What kind of tools/approaches  "they" are using ?
> Is cpld enough for general data encryption?
> (data is human voice so  8Kbps.)
> encrytion should be easy so the hacking also....
> they: whatever you say
>
> thanks
>
>
> yusuf



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