EDK : FSL macros defined by Xilinx are wrong

"andersod2" <thechrisanderson@gmail.com> wrote in message
news:99b1281a-a30f-4949-b6aa-bbf42c3824dc@y38g2000hsy.googlegroups.com...
KJ,
Thanks a lot...I think you may be right because I'm getting a lot of
latch warnings, but didn't understand why. I am using inferred ram,
which the docs say will work the same as an explicit template
instantiation if I just use the typical "reg [w:x] mem[y:z];"
notation...do you think using a template is always the better way to
go?
To infer memory in any device you need to follow the template for that
device. For FPGAs, you typically have only synchronous memory (as rickman
and Peter have pointed out), the basic template for this type of memory, in
VHDL is...

process(clk)
begin
if rising_edge(clk) then
if (write_enable = '1') then
ram(write_address) <= write_data;
end if;
read_data <= ram(read_address);
end if;
end process;

In fact I lifted the code for
my mem module from a verilog site...
Hopefully one that produces synthesizable Verilog code.

if there's a a way I can guarantee
that the inferred ram will be put in a block I would very much like to
know as I find it much easier to work with than the template. Is that
a constraints thing?
As I mentioned in the first post, I've found occasion where I had to add an
attribute to the 'read_address' signal in order to get the tool to use the
internal memory. I would suggest:
- Take the above snippet of code (or peruse Xilinx's website for their
template) and get that working in Verilog.
- Build just that module and see if it does indeed get built correctly using
the internal memory.
- Integrate that into your real design and rebuild and check that it also
gets built correctly (this is the point where I found that it wasn't and
needed the extra attribute attached to 'read_address).
- If all else fails, open a case with Xilinx.

KJ
 
Hi,
How does the vertical migration, using different parts with the same package work with the altera
cyclone 3 devices? For the EP3C40 and
EP3C16 parts in the FBGA464 packages, pin D7 is gnd on the 16K part,
and D7 is diffio on the 40K part. Also some gnd pins on the 40K part
are I/O on the 16K part. So to design a PCB that can work with both of
these parts alot of extra I/O will have to be grounded I guess?
cheers,
Jamie
Jamie,

Be careful here the documentation's not that clear, you could easily get
your fingers burnt with this migration.

We discovered that the vref's change position between the different
devices that are supposed to be 'easily' migrate-able. It took a
big spreadsheet cross-referencing the three parts (we wanted to
be able to use the '55 too) to get a pinout that was compatable.



Nial.
 
austin <austin@xilinx.com> wrote:

As many of you are aware,

Xilinx has had a re-organization to provide focus, and better serve
our customers. My role has changed, and as part of that change, I no
longer will be posting here on c.a.f.
I'm sorry to see you go. I'd like to thank you for your 'input' in
this newsgroup and wish you good luck with your new job (assignment?).
Just try to remind the guys at X that people like it when a company
official posts here every now and then.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)
 
"Antonio Pasini" <removethis_antonio.pasini@alice.it> wrote in message
news:48AAF5B2.7060508@alice.it...
And I can't even help on that, I don't know Aldec ActiveHDL.

Antonio,
Too late, you already helped. It's called 'force' in ActiveHDL as well. :)
Cheers, Syms.
 
"Pete" <petersen.curt@gmail.com> wrote in message
news:166ed929-7d1f-495f-91be-e249f810ab5b@y38g2000hsy.googlegroups.com...
I'm wondering if anyone has found a workaround to install Xilinx EDK
10.1 on Vista x64. 64-bit Vista is not "officially" supported.
However, the 32-bit version of Vista is. The majority of the
applications I use support Vista x64. I'm running some
implementations for a LX330T part, which could really benefit from the
extra memory. I really don't want to dual-boot XP and Vista x64.

Has anyone found a workaround to at least get the installer to run? I
can deal with EDK crashes (it crashes anyway, in XP). My fingers have
instinctively learned "Ctrl-S" by now.

Thank you for your help.
VMWare?
 
Pete wrote:
Looks like taco is talking about "VMWare Workstation" from a company
named vmware (vmware.com). I'm reading about it now. It
sounds......kind of scary:


It sounds great, in theory....but does it work? What happens when I'm
using EDK in my WinXP virtual machine, and I switch over to my Vista
virtual machine? I've had some bad experiences with using the Xilinx
programming cable driver on Linux, and this sounds even more
complicated to me

I'm going to get the 30-day license and give it a shot. Thanks so
much!
Hi Pete,
Right. Give it a go. It works just great, although I've not used Vista
myself. It was recommended to me by a friend who has several clients for his
design business. He has virtual machines for each one, indeed for each
individual project. Whenever Frys had a deal on a hard disk, he'd say
something like "that's 4 new PCs for $60![After rebate]". If a customer
comes back for extra features he can fire up their archived personalised
development PC, complete with whatever (broken) version of vendor software
he'd used the last time. Very cool.
As for the programming cable, dunno. Everyone on CAF always simulates their
code to death, so all our designs work in the silicon first time, every
time, so no need for programming cables. Ahem. Anyway, you can run that from
the host PC.
Cheers, Syms.
 
Do you really need to hook up a camera?

If the primary goal is to demonstrate the processing algorythm in hardware.
Then you can use a static image or video and pass the bitstream to the
hardware.
The bit stream could be passed via ethernet, usb or serial connections to
the FPGA and read back the same way.

Projects to pass data to and from a xilinx chip are scattered all over the
internet. Take a look at sites like www.fpga4fun.com
to just pass data.

If you do need to have a real time video feed, you could use the suggestion
above as a way to prove your alogrythm seperately from the circuit to
control the camera/sensor.


"Ghazal" <gzl.javed@gmail.com> wrote in message
news:2ff87bd6-ffbc-4620-b47e-1ab625856f86@2g2000hsn.googlegroups.com...
Hello,

I want to integrate an image processing algorithm (half tone pixel
converter, etc.) in Xilinx Spartan-3 FPGA (for a demo project only),
and the concern bugging me is how to get a simple image input.

* Which camera should I use
* Will it be directly controlled by the FPGA and if yes then how, if
no then how will it be controlled
* How will it physically interface with the FPGA
* What will be the image format and how will it be read by the FPGA
* Will an image sensor be easier to interface and use or digital
camera
* Will a video camera take a snapshot image which can be processed
* Will any pre-processing or analog-to-digital conversion of the
image / captured snapshot be required
* Is there a Xilinx prototype board for image capturing only

If anyone has designed / worked on cameras / images with FPGA .... do
let me know ... it will help me quick start the things here !!!
Anxiously waiting.

Regards,
Ghazal Javed
 
http://web.archive.org/web/20071122112547/http://www.xilinx.com/support/documentation/application_notes/xapp934.pdf
3.Login to Linux VM as user "devel" with password, "devuser". The root
password for this VM is "uclinux". You can login as root if you want to
configure or change system settings in the VM.
 
Jon Elson <elson@wustl.edu> wrote in news:48B30324.2000603@wustl.edu:

Hello, all,

I just got a potential project thrown in my lap. I designed an
all-analog delay generator module, with 32 delays that trigger 32
pulse widths. So, basically, 64 wide-range programmable one-shots on
one board. LVDS in, ECL out (for legacy gear). These one-shots can
be programmed from about 10 ns to 12 us in several ranges.

Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few
years ago, maybe not. So, could anyone suggest some fast FPGAs that
can handle clocks in the 500+ MHz range? I normally work with Xilinx,
but could look at some others, too. I suspect RAM-based FPGAs would
be desirable over one-time programmed. It would not be a problem to
use several smaller FPGAs to keep them from overheating at the high
clock rate. We have forced-air cooling in the equipment, but you lose
that when modules are put on extenders.

The basic circuit would look like a 13-bit counter with a 13-bit
preset register, and a zero comparator. (It could also be a 13-bit
counter that starts at zero, and a preset register that sets the
terminal count.) So, 432 FFs would do 8 channels of this dual
one-shot logic. Half of the FFs would be clocked at the 500+ MHz rate,
the other half would be essentially static.

Thanks in advance for any suggestions!
You might also like to consider using a part with a high speed serdes,
e.g. Stratix-nGX, or Virtex-nFX, etc. This allows you to sample at some
GHz, with a convenient, sensitive differential input. You can
synthesise any delay you want in multiples of the sampling period, by
rotating the internal parallel bus. The SERDES output will probably be
CML, but that is pretty easy to interface to ECL.

AFAICT, this will give you close to an order of magnitude better
performance than any other FPGA based approach.

Regards,
Allan
 
A good forum for verification questions is The Verification Guild at
http://verificationguild.com/index.php
 
"Sepideh Miller" <baghaii@gmail.com> wrote
How can I tell if I have the EDK?
Type xps in Start/Run and click OK. See waht happens...

/Mikhail
 
"knight" <krsheshu@gmail.com> wrote in message
news:01250168-8d89-41c3-8c31-7fced56fcc62@m36g2000hse.googlegroups.com...
Hi



Actuallty U1/count_or00001 is a [FG] which sources more than 20
FlipFlops reset ( which i can see in floorplanner).
And the driving net is U1/count_or0000.( this should source more than
20 FFs)
Then why is the fanout given as 11 ..? (Please refer to * in the
report)
Shouldnt it be greater than 20..?
Sir Knight,
Have a look at the net in FPGA editor. I guess that two FFs in a slice get
fed from a single pin.
HTH., Syms.
 
"G. Carvajal" <gcarvajalb@gmail.com> wrote in message
news:81ddad66-d25c-413b-9d90-11b6f563b2d4@b1g2000hsg.googlegroups.com...
Currently I'm running the test in stand alone configuration. Some
sugestions said that maybe we can try using Linux instead.
Another alternative would be eCos. There is a port available for ML403. I
haven't tried it myself, so I am not sure if it has the specific drivers you
need, but overall I think it is more suitable for an embedded application.
Xilinx kernel has a lot of bugs, especially when it comes to multithreading,
so it's no surprising that the system using it is unstable.

/Mikhail
 
In article <48B30324.2000603@wustl.edu>, Jon Elson <elson@wustl.edu> wrote:
Hello, all,

I just got a potential project thrown in my lap. I designed an
all-analog delay generator module, with 32 delays that trigger 32 pulse
widths. So, basically, 64 wide-range programmable one-shots on one
board. LVDS in, ECL out (for legacy gear). These one-shots can be
programmed from about 10 ns to 12 us in several ranges.

Why not use time delay vernier chips for this, for example SY604 or AD9501?

--
/* 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]]);}
 
On 2008-09-01, David Brown <david@westcontrol.removethisbit.com> wrote:
I believe (my own thoughts) that in an FPGA design, generating and
compiling modules is equivalent to compilation in software, and routing
and placing is equivalent to static linking. If there are components
that are isolated and communicate through standard and fixed interfaces,
then it could be argued that these are separate "works" and not part of
a complete "derived work", and the GPL/LGPL will not spread across the
interface. But the opposite could also be argued - the router and
placer software will dig into components on each side of the interface,
and the implementation of these components will depend on each other.
This of course gives you a more efficient bitstream - but it means that
the final bitstream cannot be split into separate parts and is therefore
a single combined "work".
First of all: Thanks to Genode Labs for releasing this source code under
an open source license! I hope this initiative will bring you lot of
goodwill and customers!

However, I have a few things to say regarding open source and hardware.
The license question for open source hardware is a pretty interesting one.
I feel that there are many questions here such as the one you list above.
My personal belief is that it is not legally possible to distribute a
design which contains both components under GPL and components under a more
restrictive license.

Regarding your comments about standard interfaces: A GPL program which
calls a proprietary library using a standardized calling convention
specified in the ABI can not be legally distributed AFAIK. (Ignoring the
system library exception.)


Some things to think on:
http://www.bitlaw.com/copyright/maskwork.html

Someone has actually gone to the trouble of making a license for hardware:
http://technocrat.net/d/2007/2/5/14355 <-- Some interesting discussion
regarding a draft version of this license.
http://www.tapr.org/ohl.html <-- A page with the complete license (follow
the links on the top)

Unfortunately the hardware license above is not aimed at HDL code according
to the author.

Another hardware license is the one included in Opencores' DDR SDRAM
controller: http://www.opencores.org/projects.cgi/web/ddr_sdr/overview
(Unfortunately I cannot link directly to the license file as Opencores now
requires you to register to look at files in the CVS repository.)
I'm not sure how much thought that went into the creation of this license
and I'm therefore not willing to use it myself without reading the opinion
of a lawyer about it.


My personal belief is that there might be some problems with GPL as a license
for HDL code. On the other hand, Sun has released OpenSparc under the GPL
which I see as a clear indication that the GPL is a viable license for
hardware. See http://www.opensparc.net/faqs/licensing/ for what they think
this means in a hardware design. (They are using GPLv2 at the moment.)


/Andreas
 
On 2008-09-03, David Brown <david@westcontrol.removethisbit.com> wrote:
Sun is a company with a long history of love/hate relationships with
open source and licenses, so their choices are never a good indication
of anything.
What I meant was that Sun's choice is a clear indication that they expect
the GPL to work correctly for hardware even though it is originally
designed as a copyright license for software.

/Andreas
 
"tullio" <tullio.grassi@gmail.com> wrote in message
news:e8e8899d-614f-4021-ab60-056545c3d260@b30g2000prf.googlegroups.com...
So in fact I don't need to prove that the machine does not recover
from illigal states, because recovering is not guaranteed without
"safe" option.
As pointed out previously though, 'recovery' is usually hiding a symptom of
the real underlying problem and even if the state machine 'recovers' the
things that depend on it may not.

In
fact in the real hardware I observe a mis-behavior
compatible with an illigal state immediately after FPGA configuration
(about 1 time in 600 cycles), as if the initial value is not set
properly.
This is a timing problem, the most likely cause is a setup time violation on
some input relative to the clock when you're coming out of reset. For
example, what do you have in your design to protect you for when the part
finishes configuration? The end of configuration is generally totally
asynchronous to any free running oscillator clock input that you may have to
the design. Unless the input clocks to the design are stopped during and
slightly after configuration it is darn near impossible to bring the part
reliably out of configuration and into a working state. That's the reason
that the first task of the design is to generate a synchronized internal
reset to the rest of the design and THEN start doing it's thing.

1 in 600 failures is almost always a symptom of timing problems, find that
to fix your design. The other possible cause of such seemingly random
function is power supply issues.

I often have FSMs that don't need any external reset and I have not
coded it to save resouces.
It's a false savings...and this design is an example of why that is.

I guess I will either add a reset and/or explicitly code the unwanted
states as suggested by Jim.
I'd suggest getting to the root cause of your design issue (it's not whether
the state machine is 'safe' or not), it's most likely timing and the lack of
a synchronized reset. Otherwise, you're just guessing and coming to
incorrect conclusions that 'seem' to work this time but will fail you next
time (just like the way that the lack of designing in a reset as a general
practice has failed you on this design).

Good luck,

Kevin Jennings
 
MikeWhy (boat042-nospam@yahoo.com) wrote:
: <randomdude@gmail.com> wrote in message
: news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
: > My main idea at the moment is an encrypting DIMM module, intended to
: > protect against 'cold boot' attacks, and the scenario that an attacker
: > is presented with a freshly-turned-off machine with some juicy secret
: > still in a DIMM module, which they can then remove, throw in to some
: > socket, and dump.

: Perhaps the first order of business is to establish that this is a viable
: attack. Can someone really do that? SDRAM refresh cycles are on the order
: of <10 usec, otherwise data would be lost. I would think much simpler and
: more severe "attacks" would be available once you gained physical control of
: the machine. Cutting out the living and still beating heart idea tops them
: all in complexity.

SDRAM can last a surprisingly long time - I have a board that stores an
image in some, and if you turn it off for a few mins and turn it back on,
the image is still recognisable - if badly corrupted. Corruption starts
within microsecconds but isn't instant or total.

Regards
Chris
 
"Gael Paul" <gael.paul@gmail.com> wrote in message
news:30d93278-53bc-49ec-bf5f->
Finally, I noticed something worth investigating in your data: the 8-
bit/135 implementation takes ~11 LEs, while the 24-bit/135
implementation takes ~32 LEs. This seems wrong. Indeed, with a max
value of 134, the synthesis tool should trim down the 24-bit counter
to just 8 bits.
Forgot to add, that the reason for posting the results for the 24 bit
counter that counts in a restricted range that *could* be covered by 9
independent outputs (8 bits for the bits that are actually counting, 1 bit
to zero out the other 16 outputs) is for those people who like to suggest
that 'reachability analysis' will take care of them and those outputs that
will always end up being 0 (under normal operating conditions) will be
detected by the synthesizer which will then cause all the logic to be
magically synthesized away and collapse down to generation of a single '0'.

This example showed that such analysis, while it could have been done is not
something that can always be counted on to be performed and that there will
be a price to be paid for assumming that it will be done when in fact it is
not. Feel free to post the synthesis tool used and the settings required to
obtain the optimal synthesis output.

KJ
 
hi

Can anyone tell me how can i multiply two signed numbers in FPGA.
How the logic is really implemented..
ie., if i multiply two signed numbers are they multiplying the
positive number and the 2's complement (if the number is negative)
directly ..?
Or are they really changing the negative number to positive and do
normal multiplication and appends the sign accordingly..?
And is the positive number, and its 2's complement form same always...?
It depends on the FPGA and the way you specify the multiplication
operation.

If it uses a hardware "DSP" or "MAC" resource, the logic internal to that
block will know what to do with the sign bits.

Otherwise, the synthesis tool will know how to handle the bits if, for
instance, you are writing in VHDL and declare the signals to be of type
'signed'.

What FPGA are you using?
What language are you writing in?
Why don't you do some experiments and look at the log files and gate-level
netlist?
Have you tried multiplying -1 x -1?
 

Welcome to EDABoard.com

Sponsor

Back
Top