Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
Muzaffer Kal wrote: > Do you have access to DC, PC, PT and similar tools through your > current employer? That would be the only way to get at them. ASIC > tools are extremely expensive and would be quite difficult to acquire > any other way. If you have lots of time and passion, you can write the tools yourself: http://www.ultratechnology.com/tape1-2.htm -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 138201
On 2009-02-09, FredrikH <fredrik.holmsten@gmail.com> wrote: > Thanks for a very detailed answer. Is this DSP processor of yours > something that you distribute in any way? Is there a license > associated with it? Or is it something for opencores.org!? No problem, it was an interesting challenge to think about how our work could be adapted to a very parallel solution. In regards to licensing we haven't really thought about distributing the core in any way. (Neither commercially or as open source. We just haven't had time to consider this seriously.) > In any way I guess it requires good knowledge and a great deal of work > to implement it. It?s not a push button flow and that is more or less > what I was looking for when I started searching for Mp3-cores. Maybe a > naive starting point, but this project I?m working on will probably > not give me a day for studying the Mp3 decoding and encoding in > detail. > > I don?t need to decode or encode more than six channels simultaneously > so even if the encoding requires more processing power/resources it > seems to be an easy match to fit everything in a 30 000 LUT FPGA. I > don?t know yet what kind of FPGA I?ll be using. Maybe a Spartan-6? Given the lack of time and the modest amount of channels required I would just slap as many soft core processors on your FPGA as required. Perhaps some tiny accelerators could be added, but it is doubtful that you would have time to do that in a single day. Unfortunately I don't have any experiences with MP3 encoding, but I guess it will be more expensive than decoding, depending on the quality you need. It would be interesting if you could post your experiences after you have implemented your system. /AndreasArticle: 138202
On Feb 9, 5:57=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Mon, 09 Feb 2009 10:14:09 +0000, Jonathan Bromley wrote: > >But there's another idea coming... > > which is to time-division mux the two additions. > This degrades the jitter to 2 master clock periods, > but gives what I believe to be the most compact > and fastest possible implementation for a phase > accumulator whose modulus is not a power of 2. > I removed the reset because it's fairly useless. > > As with the earlier implementation, this one > can only provide output rates up to Fc/2. > > =A0 library ieee; > =A0 use ieee.std_logic_1164.all; > =A0 use ieee.numeric_std.all; > > =A0 entity rate_gen is > =A0 =A0 generic ( ref_Hz: positive :=3D 50_000_000 ); > =A0 =A0 port > =A0 =A0 =A0 ( clock : in =A0std_logic > =A0 =A0 =A0 ; rate =A0: in =A0unsigned > =A0 =A0 =A0 ; pulse : out std_logic > =A0 =A0 =A0 ); > =A0 end; > > =A0 architecture RTL_2ph of rate_gen is > =A0 begin > =A0 =A0 process (clock) > =A0 =A0 =A0 -- Halve the modulus to account for 2-phase operation > =A0 =A0 =A0 constant modulus: integer :=3D ref_Hz/2; > =A0 =A0 =A0 -- This flag controls the adder multiplexing > =A0 =A0 =A0 variable phase: boolean; > =A0 =A0 =A0 variable count: integer range -2**rate'length to modulus-1 := =3D 0; > =A0 =A0 begin > =A0 =A0 =A0 if rising_edge(clock) then > =A0 =A0 =A0 =A0 pulse <=3D '0'; > =A0 =A0 =A0 =A0 if phase then > =A0 =A0 =A0 =A0 =A0 count :=3D count - to_integer(rate); > =A0 =A0 =A0 =A0 elsif count < 0 then > =A0 =A0 =A0 =A0 =A0 count :=3D count + modulus; > =A0 =A0 =A0 =A0 =A0 pulse <=3D '1'; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 phase :=3D not phase; > =A0 =A0 =A0 end if; > =A0 =A0 end process; > > =A0 end; > > Thanks for all the comments. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Jonathan, I was intrigued by your first posting, but couldn't get around to thinking about it more until today. I have not seen that particular trick before - you're basically just trying to increase the bit-level correlation between two of the adder inputs (M and 2M) in hopes that the synthesizer can make good use of the ensuing simplifications that fall out. It's very nice conceptually, but there's always the risk that the synthesizer can't see your idea. Your two-phase idea is also slick. When doing numerical work, one always has the sense that by serializing the operations, one could use less logic and create a more compact and elegant solution. This two- phase concept seems to find the sweet spot between generalized state- machine-based serial operations and the brute force all-in-one clock cycle version. I haven't tried synthesizing it yet but I'm inclined to steal this for my next design if it's really as clean as it looks. - KennArticle: 138203
On Feb 4, 10:05=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > Hi All, > > I need help, and am willing to pay for it. If you can > help me solve my problem, I will pay you. Name your > price, and see if you can help me: > > Here is my problem: > > I am running Fedora Core 7, x86_86, kernel 2.6.28. > I have libusb installed, and everything works fine with > ISE 10.1. However, I am forced to upgrade to 10.1 sp3. > And that's where everything breaks. I need for it to > work "normally" with libusb, so I can use impact and > chipscope. I can switch to 10.1 and it works, I go to sp3, > and it is broken. Yeah, I do have XIL_IMPACT_USE_LIBUSB > set. > > If you think you can help, please email me privately: > rudolf.usselmann at gmail dot com > > Time is of essence ! > > Thanks ! > rudi > > This is how impact fails: > > impact -batch etc/download.cmd > < SNIP All output from Impact > Clearly Xilinx has a new version of the firmware for the USB cables and Impact is trying to download it. One fix would be to go back to the old firmware and force the new version of Impact to use it. Hopefully it won't know the difference. Another thing is to check the version of the firmware loader that you are using. This used to be a package that was already installed by the distro's. The application was called fxload. You mean need to update the version of this installed.Article: 138204
Antti wrote:
> Mike I am not that dumb ;)
I'm the dumb one.
I had to do that exercise to figure out what the discussion was about.
I'm a package guy, not a wrapper guy ;)
-- Mike Treseler
Article: 138205On Feb 9, 1:36=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Mon, 9 Feb 2009 01:18:21 -0800 (PST), uraniumore...@gmail.com > wrote: > > >Does anyone know how I can generate a pulser of maximum repition rate > >of 50 Mhz in verilog .. into my existing design ? I'd like to simulate > >this signal before I use the actual pulser into the board > > I think you want a clock source. Here is one way you can generate it: > > `timescale 1ns/100fs > reg clk; > initial > begin > =A0 =A0 =A0 =A0 pck =3D 0; > =A0 =A0 =A0 =A0 forever clk =3D #10 ~clk; > end > > This clock toggles at 50 MHz as you want (ie 10ns high, 10 ns low) and > you can change the number 10 to your needs. > Please note that this is only for testbench usage and you can't > actually put this in your fpga. You have to use an oscillator on your > board to generate a similar clock to drive into your fpga. > > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Serviceshttp://www.dspia.com Hi, I was did make myself clear. I would like to have a variable pulesr, maximum 50 Mhz. ThanksArticle: 138206
On Feb 9, 2:06=A0am, googler <pinaki_...@yahoo.com> wrote: > Hi all, > > I am an ASIC designer who works mostly on the front end (RTL coding). > I want to teach myself on how things are done in the backend by > working on small (hobby) projects. My main requirement is not just to > learn the concepts, but to gain hands-on experience using some of the > industry standard tools (like Design Compiler, PrimeTime etc) and > formats (like SDC files). > > (1) How can I do this on my own without spending a lot of money for > all the different tools? My first choice, of course, is the most > common tools like DC or PT, but if there are cheaper but similar tools > available, that may be fine too. > (2) I had earlier been thinking about using an FPGA board for this, > but will the same tools (as mentioned earlier) work for FPGA? How > different are the tools that come with the FPGA boards? > > I got myself a copy of the book "Advanced ASIC Chip Synthesis using > Synopsys Design Compiler, Physical Compiler and PrimeTime". So I would > prefer something (that is, what tools or which platform) that will not > be too different from what the book talks about. > > Thanks in advance. I've done ASIC design on the front and back ends. First, DC is not considered a back-end tool. Back-end typically refers to physical design, such as P&R, CTS, parasitic extraction, DRC, LVS, etc. This is not the realm of the hobbyist unless he's a millionaire (licenses are in the tens to hundreds of thousands of dollars) or works for a company that has the tools. If your company does have the tools, you may find it difficult to get access to them if the licenses are being used for company projects. I actually enjoy the RTL design more than the back-end work, which can be a tedious grind. RTL design allows for creativity; back-end work, though requiring a great deal of hard-earned technical skill, can really become a slog. The tools require quite an investment of time to master. The nuances, bugs, and quirks of the tools are initially overwhelming to the beginner. On the upside, it's satisfying to learn the whole IC tool flow, and it will make you a better RTL designer because you'll know what design structures are handled well by the tools. Darol KlawetterArticle: 138207
On Sun, 08 Feb 2009 21:32:40 +0000, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:
>On Sun, 8 Feb 2009 10:27:08 -0800 (PST), Antti wrote:
>
>>ok, now i KNOW too
>>used Jons unmodifed code :)
>
>It simulates correctly too, although of course it needs to
>be wrapped in something that provides a signal to connect
>to its unconstrained input port. I haven't tried it with
>ISIM just yet, but I believe the code is strictly VHDL-93
>compliant and therefore it is NOT MY FAULT if some simulator
>cannot handle it.
Well ISIM certainly has trouble with a few VHDL constructs, so I was curious
enough to try and find the problem here. I feel Xilinx sincerely want to make it
work properly, so at one point I had 8 Webcases open, most of them reporting
ISIM defects. Even 10.1.03 is significantly better than 10.1.01.
Taking the heavy hints to build a wrapper entity, I let ISE do its "new source
... VHDL Module" thing (and what exactly is a VHDL Module?), added a direct
entity instantiation, and stole Antti's intermediate signal from
>i constrained the signal connected to rate in the wrapper as:
>signal rate : unsigned(15 downto 0) := X"2580";
and tried synthesis...
ERROR:HDLParsers:800 - "/home/brian/projects/play/baudrate/baudgen.vhd" Line 50.
Type of rate is incompatible with type of rate.
That was easily fixed...
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--use IEEE.STD_LOGIC_ARITH.ALL;
--use IEEE.STD_LOGIC_UNSIGNED.ALL;
use ieee.numeric_std.all;
... but grrrrrrr....
then synthesis was as expected.
To try ISIM...
1) "New Source - VHDL Testbench" and associate the DUT with the wrapper entity.
2) I made three trivial changes to the testbench ...
(a) comment out "USE ieee.std_logic_unsigned.all;"
(oddly enough, numeric_std was already there!)
(b) set the clock frequency
constant clock_period : time := 20ns; -- was 1 us
(c) change the startup delay
wait for 100ns; -- was 100ms
This would have made more difference if I had remembered to drive the Reset
signal, but never mind...
ISIM reported
ERROR:HDLCompiler:69 - "baudgen.vhd" Line 47. rate_gen is not declared
at which point I changed the instantiation of Jonathan's entity in my wrapper,
to specify the "work" library.
Gen: entity rate_gen
to
Gen: entity work.rate_gen
and ISIM simply worked.
I don't know if this (requirement to specify the "work" library) is an ISIM
defect, but I think it's a lesser problem than the rest of ISE, including XST,
has with VHDL libraries - ignoring them altogether.
Which means you can use components with the same name in different libraries,
and the simulator (ISIM included) will pick the one you specify, but XST will
simply pick whichever it feels like, ignoring your library/use/embedded
configurations. (That's supposed to be fixed in ISE11. We'll see)
ISIM still has problems though:
(1) the wave viewer won't show a 20ns pulse on a 1ms window, though the "find
next edge" button and zooming in shows they are really there...
(2) Increasing the baud rate
signal rate : unsigned(15 downto 0) := X"25800";
ISIM spotted the deliberate mistake and an error message flashed past,
but then it ran the out of date sim anyway (which is a VERY bad design decision
IMO)
But fixing the mistake
signal rate : unsigned(19 downto 0) := X"25800";
and simulating for 100us, all was well.
Antti, did you have a different problem?
- Brian
Article: 138208On Feb 9, 11:19=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sun, 08 Feb 2009 21:32:40 +0000, Jonathan Bromley > > <jonathan.brom...@MYCOMPANY.com> wrote: > >On Sun, 8 Feb 2009 10:27:08 -0800 (PST), Antti wrote: > > >>ok, now i KNOW too > >>used Jons unmodifed code :) > > >It simulates correctly too, although of course it needs to > >be wrapped in something that provides a signal to connect > >to its unconstrained input port. =A0I haven't tried it with > >ISIM just yet, but I believe the code is strictly VHDL-93 > >compliant and therefore it is NOT MY FAULT if some simulator > >cannot handle it. =A0 > > Well ISIM certainly has trouble with a few VHDL constructs, so I was curi= ous > enough to try and find the problem here. I feel Xilinx sincerely want to = make it > work properly, so at one point I had 8 Webcases open, most of them report= ing > ISIM defects. Even 10.1.03 is significantly better than 10.1.01. > > Taking the heavy hints to build a wrapper entity, I let ISE do its "new s= ource > ... VHDL Module" thing (and what exactly is a VHDL Module?), added a dire= ct > entity instantiation, and stole Antti's intermediate signal from>i constr= ained the signal connected to rate in the wrapper as: > >signal rate : unsigned(15 downto 0) :=3D X"2580"; > > and tried synthesis... > > ERROR:HDLParsers:800 - "/home/brian/projects/play/baudrate/baudgen.vhd" L= ine 50. > =A0 =A0 =A0 =A0 Type of rate is incompatible with type of rate. > > That was easily fixed... > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > --use IEEE.STD_LOGIC_ARITH.ALL; > --use IEEE.STD_LOGIC_UNSIGNED.ALL; > use ieee.numeric_std.all; > ... but grrrrrrr.... > then synthesis was as expected. > > To try ISIM... > 1) "New Source - VHDL Testbench" and associate the DUT with the wrapper e= ntity. > 2) I made three trivial changes to the testbench ... > (a) comment out "USE ieee.std_logic_unsigned.all;" > (oddly enough, numeric_std was already there!) > (b) set the clock frequency > =A0 =A0 constant clock_period : time :=3D 20ns; -- was 1 us > (c) change the startup delay > =A0 =A0 wait for 100ns; -- was 100ms > This would have made more difference if I had remembered to drive the Res= et > signal, but never mind... > > ISIM reported > ERROR:HDLCompiler:69 - "baudgen.vhd" Line 47. rate_gen is not declared > > at which point I changed the instantiation of Jonathan's entity in my wra= pper, > to specify the "work" library. > Gen: entity rate_gen > to > Gen: entity work.rate_gen > > and ISIM simply worked. > > I don't know if this (requirement to specify the "work" library) is an IS= IM > defect, but I think it's a lesser problem than the rest of ISE, including= XST, > has with VHDL libraries - ignoring them altogether. > I believe that the requirement to use the "work" prefix is a consequence of the name visibility rules in VHDL. The reason you can usually get away with a non-prefixed simple component instance (as opposed to an entity) is that you've already made the name visible by "use.some_component_pkg.all". (UNISIM, VSIM, etc), or else explicitly defined your component with the rest of your declarations. A "use work.all" should achieve the same end. > Which means you can use components with the same name in different librar= ies, > and the simulator (ISIM included) will pick the one you specify, but XST = will > simply pick whichever it feels like, ignoring your library/use/embedded > configurations. (That's supposed to be fixed in ISE11. We'll see) > > ISIM still has problems though: > (1) the wave viewer won't show a 20ns pulse on a 1ms window, though the "= find > next edge" button and zooming in shows they are really there... > > (2) Increasing the baud rate > signal rate : unsigned(15 downto 0) :=3D X"25800"; > ISIM spotted the deliberate mistake and an error message flashed past, > but then it ran the out of date sim anyway (which is a VERY bad design de= cision > IMO) > > But fixing the mistake > signal rate : unsigned(19 downto 0) :=3D X"25800"; > and simulating for 100us, all was well. > > Antti, did you have a different problem? > > - BrianArticle: 138209
On Feb 9, 6:19=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sun, 08 Feb 2009 21:32:40 +0000, Jonathan Bromley > > <jonathan.brom...@MYCOMPANY.com> wrote: > >On Sun, 8 Feb 2009 10:27:08 -0800 (PST), Antti wrote: > > >>ok, now i KNOW too > >>used Jons unmodifed code :) > > >It simulates correctly too, although of course it needs to > >be wrapped in something that provides a signal to connect > >to its unconstrained input port. =A0I haven't tried it with > >ISIM just yet, but I believe the code is strictly VHDL-93 > >compliant and therefore it is NOT MY FAULT if some simulator > >cannot handle it. =A0 > > Well ISIM certainly has trouble with a few VHDL constructs, so I was curi= ous > enough to try and find the problem here. I feel Xilinx sincerely want to = make it > work properly, so at one point I had 8 Webcases open, most of them report= ing > ISIM defects. Even 10.1.03 is significantly better than 10.1.01. > > Taking the heavy hints to build a wrapper entity, I let ISE do its "new s= ource > ... VHDL Module" thing (and what exactly is a VHDL Module?), added a dire= ct > entity instantiation, and stole Antti's intermediate signal from>i constr= ained the signal connected to rate in the wrapper as: > >signal rate : unsigned(15 downto 0) :=3D X"2580"; > > and tried synthesis... > > ERROR:HDLParsers:800 - "/home/brian/projects/play/baudrate/baudgen.vhd" L= ine 50. > =A0 =A0 =A0 =A0 Type of rate is incompatible with type of rate. > > That was easily fixed... > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > --use IEEE.STD_LOGIC_ARITH.ALL; > --use IEEE.STD_LOGIC_UNSIGNED.ALL; > use ieee.numeric_std.all; > ... but grrrrrrr.... > then synthesis was as expected. > > To try ISIM... > 1) "New Source - VHDL Testbench" and associate the DUT with the wrapper e= ntity. > 2) I made three trivial changes to the testbench ... > (a) comment out "USE ieee.std_logic_unsigned.all;" > (oddly enough, numeric_std was already there!) > (b) set the clock frequency > =A0 =A0 constant clock_period : time :=3D 20ns; -- was 1 us > (c) change the startup delay > =A0 =A0 wait for 100ns; -- was 100ms > This would have made more difference if I had remembered to drive the Res= et > signal, but never mind... > > ISIM reported > ERROR:HDLCompiler:69 - "baudgen.vhd" Line 47. rate_gen is not declared > > at which point I changed the instantiation of Jonathan's entity in my wra= pper, > to specify the "work" library. > Gen: entity rate_gen > to > Gen: entity work.rate_gen > > and ISIM simply worked. > > I don't know if this (requirement to specify the "work" library) is an IS= IM > defect, but I think it's a lesser problem than the rest of ISE, including= XST, > has with VHDL libraries - ignoring them altogether. > > Which means you can use components with the same name in different librar= ies, > and the simulator (ISIM included) will pick the one you specify, but XST = will > simply pick whichever it feels like, ignoring your library/use/embedded > configurations. (That's supposed to be fixed in ISE11. We'll see) > > ISIM still has problems though: > (1) the wave viewer won't show a 20ns pulse on a 1ms window, though the "= find > next edge" button and zooming in shows they are really there... > > (2) Increasing the baud rate > signal rate : unsigned(15 downto 0) :=3D X"25800"; > ISIM spotted the deliberate mistake and an error message flashed past, > but then it ran the out of date sim anyway (which is a VERY bad design de= cision > IMO) > > But fixing the mistake > signal rate : unsigned(19 downto 0) :=3D X"25800"; > and simulating for 100us, all was well. > > Antti, did you have a different problem? > > - Brian Yes Brian little different: the wrapper: -- this works for ISIM and XST use IEEE.STD_LOGIC_1164.ALL; --use IEEE.STD_LOGIC_ARITH.ALL; --use IEEE.STD_LOGIC_UNSIGNED.ALL; use ieee.numeric_std.all; -- this works for XST but not ISIM use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; So i did MINIMAL fix to get pass XST that was not enough to pass with ISIM so the original code can pass XST/ISIM with fully proper wrapper :) nice excercise AnttiArticle: 138210
On Feb 9, 6:09=A0pm, uraniumore...@gmail.com wrote: > On Feb 9, 1:36=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Mon, 9 Feb 2009 01:18:21 -0800 (PST), uraniumore...@gmail.com > > wrote: > > > >Does anyone know how I can generate a pulser of maximum repition rate > > >of 50 Mhz in verilog .. into my existing design ? I'd like to simulate > > >this signal before I use the actual pulser into the board > > > I think you want a clock source. Here is one way you can generate it: > > > `timescale 1ns/100fs > > reg clk; > > initial > > begin > > =A0 =A0 =A0 =A0 pck =3D 0; > > =A0 =A0 =A0 =A0 forever clk =3D #10 ~clk; > > end > > > This clock toggles at 50 MHz as you want (ie 10ns high, 10 ns low) and > > you can change the number 10 to your needs. > > Please note that this is only for testbench usage and you can't > > actually put this in your fpga. You have to use an oscillator on your > > board to generate a similar clock to drive into your fpga. > > > Muzaffer Kal > > > DSPIA INC. > > ASIC/FPGA Design Serviceshttp://www.dspia.com > > Hi, > > I was did make myself clear. I would like to have a variable pulesr, > maximum 50 Mhz. > > Thanks I think you made something very clear. AnttiArticle: 138211
On Mon, 9 Feb 2009 08:52:59 -0800 (PST), Antti <Antti.Lukats@googlemail.com>
wrote:
>On Feb 9, 6:19 pm, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> Well ISIM certainly has trouble with a few VHDL constructs, so I was curious
>> enough to try and find the problem here.
[synth]
>> ERROR:HDLParsers:800 - "/home/brian/projects/play/baudrate/baudgen.vhd" Line 50.
>> Type of rate is incompatible with type of rate.
[sim]
>> and ISIM simply worked.
>> Antti, did you have a different problem?
>>
>> - Brian
>
>Yes Brian little different:
>
>the wrapper:
>-- this works for XST but not ISIM
>use IEEE.STD_LOGIC_1164.ALL;
>use IEEE.STD_LOGIC_ARITH.ALL;
>use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
>So i did MINIMAL fix to get pass XST
>that was not enough to pass with ISIM
Interesting because that's exactly the conditions that gave me the XST above ...
type mismatch between IEEE.STD_LOGIC_UNSIGNED (in the wrapper) and numeric_std
(in Jonathan's code).
So I don't see how you got it through XST...
>
>so the original code can pass XST/ISIM
>with fully proper wrapper :)
>
>nice excercise
and ISIM is (somewhat) redeemed.
Modelsim is clearly better.
But ISIM is:
cross-platform (I use it on Linux)
cross-language (there is ONE model I need, only available in Verilog)
supporting SmartModel (unlike Modelsim XE at all, or PE + extra cost)
and a lot less than $30k
- Brian
Article: 138212On Mon, 9 Feb 2009 08:41:39 -0800 (PST), kennheinrich@sympatico.ca wrote: >On Feb 9, 11:19 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> ISIM reported >> ERROR:HDLCompiler:69 - "baudgen.vhd" Line 47. rate_gen is not declared >> at which point I changed the instantiation of Jonathan's entity in my wrapper, >> to specify the "work" library. >> Gen: entity rate_gen >> to >> Gen: entity work.rate_gen >> >> and ISIM simply worked. >> >> I don't know if this (requirement to specify the "work" library) is an ISIM >> defect, but I think it's a lesser problem than the rest of ISE, including XST, >> has with VHDL libraries - ignoring them altogether. >> > >I believe that the requirement to use the "work" prefix is a >consequence of the name visibility rules in VHDL. The reason you can >usually get away with a non-prefixed simple component instance (as >opposed to an entity) is that you've already made the name visible by >"use.some_component_pkg.all". (UNISIM, VSIM, etc), or else explicitly >defined your component with the rest of your declarations. Which ISIM also appears to handle correctly. > A "use work.all" should achieve the same end. And in ISIM it does. At which point I believe that >> Gen: entity rate_gen (without your use clause) should have failed in ISE too, at least until 11.1 comes out. (I see 11.1 "breaking" many existing projects; or at least pointing out they were already broken...) - BrianArticle: 138213
On Feb 9, 8:07=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Mon, 9 Feb 2009 08:52:59 -0800 (PST), Antti <Antti.Luk...@googlemail.c=
om>
> wrote:
>
>
>
>
>
> >On Feb 9, 6:19=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
> >wrote:
> >> Well ISIM certainly has trouble with a few VHDL constructs, so I was c=
urious
> >> enough to try and find the problem here.
> [synth]
> >> ERROR:HDLParsers:800 - "/home/brian/projects/play/baudrate/baudgen.vhd=
" Line 50.
> >> =A0 =A0 =A0 =A0 Type of rate is incompatible with type of rate.
> [sim]
> >> and ISIM simply worked.
> >> Antti, did you have a different problem?
>
> >> - Brian
>
> >Yes Brian little different:
>
> >the wrapper:
> >-- this works for XST but not ISIM
> >use IEEE.STD_LOGIC_1164.ALL;
> >use IEEE.STD_LOGIC_ARITH.ALL;
> >use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> >So i did MINIMAL fix to get pass XST
> >that was not enough to pass with ISIM
>
> Interesting because that's exactly the conditions that gave me the XST ab=
ove ...
> type mismatch between =A0IEEE.STD_LOGIC_UNSIGNED (in the wrapper) and num=
eric_std
> (in Jonathan's code).
>
> So I don't see how you got it through XST...
>
>
>
> >so the original code can pass XST/ISIM
> >with fully proper wrapper :)
>
> >nice excercise
>
> and ISIM is (somewhat) redeemed.
>
> Modelsim is clearly better.
>
> But ISIM is:
> =A0 =A0 =A0 =A0 cross-platform (I use it on Linux)
> =A0 =A0 =A0 =A0 cross-language (there is ONE model I need, only available=
in Verilog)
> =A0 =A0 =A0 =A0 supporting SmartModel (unlike Modelsim XE at all, or PE +=
extra cost)
> =A0 =A0 =A0 =A0 and a lot less than $30k
>
> - Brian
Brian
plese LOOK below, my complete wrapper.
AS is it passes XST until bit file all ok.
but yikes in ISIM
----------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
--use ieee.numeric_std.all;
entity rate_gen_top is
Port ( clock : in STD_LOGIC;
reset : in STD_LOGIC;
pulse : out STD_LOGIC);
end rate_gen_top;
architecture Behavioral of rate_gen_top is
COMPONENT rate_gen
PORT(
clock : IN std_logic;
reset : IN std_logic;
rate : IN unsigned; -- manually fixed here, ISE bug creating
template! converted unsigned to std_logic !
pulse : OUT std_logic
);
END COMPONENT;
signal rate : unsigned(15 downto 0) :=3D X"2580"; -- 9600 baud
begin
Inst_rate_gen: rate_gen PORT MAP(
clock =3D> clock,
reset =3D> reset,
rate =3D> rate,
pulse =3D> pulse);
end Behavioral;
Article: 138214
On Mon, 9 Feb 2009 10:18:27 -0800 (PST), Antti wrote:
>plese LOOK below, my complete wrapper.
>AS is it passes XST until bit file all ok.
>but yikes in ISIM
The wrapper (collaborative effort, you + ISE) is
bad VHDL (explanation below). XST is tolerating
it, but should not. ISIM is right here (along with
all the other simulators).
>use IEEE.STD_LOGIC_ARITH.ALL;
OK, this use-clause provides definition of type UNSIGNED.
>architecture Behavioral of rate_gen_top is
>
> COMPONENT rate_gen
> PORT(
> clock : IN std_logic;
> reset : IN std_logic;
> rate : IN unsigned;
> pulse : OUT std_logic
> );
> END COMPONENT;
OK, so the COMPONENT has a port "rate" whose data
type is "ieee.std_logic_arith.unsigned". So far, so good.
>signal rate : unsigned(15 downto 0) := X"2580"; -- 9600 baud
And this signal is of the same type. Also good.
>begin
> Inst_rate_gen: rate_gen PORT MAP(
> clock => clock,
> reset => reset,
> rate => rate,
Still good. You've wired port "rate" to signal "rate"
and they both have exactly the same data type.
So, what's wrong? Nothing. BUT... when you try to
elaborate the design, port "rate" on the component
must bind to port "rate" on the entity; the component's
port is "ieee.std_logic_arith.unsigned" and the
entity's is "ieee.numeric_std.unsigned". Two different
data types. Not compatible. XST should have choked on it.
Now, this is somewhat negligent on the part of XST, but
let's see what the bug report should look like...
Dear Xilinx,
XST compiled my code exactly the way I wanted it.
Please fix XST so that it will NOT compile my code.
Yours sincerely,
A. Masochist.
I don't see Xilinx exactly being flooded with
that kind of case; do you? :-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 138215Hopefully I=92ll get more than a single day for putting everything together so your suggestion to simply use as many soft cores as necessary with some acceleration is probably the way to go. Many thanks for your input on this issue. /FredrikArticle: 138216
emeb wrote: > On Feb 7, 8:13 pm, John Eaton <nos...@spam.com> wrote: > >> Digilent (www.digilentinc.com) sells a nice usb to 6 pin cable for >> $37.95. Problem is it only works with their windoze software. Would be >> nice if they supported linux. > > I've got one of these and it works nicely (very fast) under WinXP, > although the driver application has a few limitations (can only > configure, not verify / readback). There is an open source app that > purports to drive this device here: > > http://sourceforge.net/projects/xilprg > > It's a few years out of date and the author seems to have dropped off > the face of the planet. I've tried this with my Digilent USB<->JTAG > cable and while it recognizes the device it can't seem to detect any > devices on the bus. Hanging a 'scope probe from the JTAG signals shows > that they're not moving, so I suspect there are still some issues. It > might be a good starting point for someone who knows more about this > than I do. > > Eric (not the OP) I also tried xilprg with the same results. Glad to see that I'm not the only one who can't get anything to work. John EatonArticle: 138217
On Sun, 08 Feb 2009 21:54:45 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >The last line requires TWO adders, in addition to the >multiplexer created by the IF. This causes a significant >performance hit. That's what I was trying to fix. I did >it by saying... You can add 3 numbers in the same time as 2 because the maximum carry generated at any bit position is still '1'. I.e. '1' + '1' + '1' is still '11'. OK, works for 4-input LUTs. 4 numbers will make the carry chain more complicated. I have not tried if Virtex carry chains can take advantage of this. If yes, the mux should be possible in the same block. regards, GerhardArticle: 138218
On Feb 9, 1:35=A0pm, John Eaton <no_s...@spam.com> wrote: > I also tried xilprg with the same results. Glad to see that I'm not the > only one who can't get anything to work. We should start a "Disappointed xilprog users" support group. :) Ideally the thing to do would be to figure out the USB commands sent to the cable by means of a USB snooper while running the Digilent tools under WinXP. Reverse engineering the protocol should be fairly easy from there. This would also allow one to add support for this cable to the urJTAG suite which seems to be the most active open source JTAG tool out there. EricArticle: 138219
Does anyone know how to do this? I could only use CIP to create and add IP core to a project, but couldn't figure out how to remove from the project. (And I don't mean just deleting an instance of a user core). ThanksArticle: 138220
Has anyone come across this problem when and XPS project is opened: WARNING: MDT -- Use of reposritory located at C:\Xilinx \10.1\edk_user_repository\ is now deprecated. It is recommended that you use Gloabl Search Path preference to specify search paths that apply to all projects. I've gone into Edit->Preference and set Global Search Path to the project directory but I got an error saying that the directory must be 2 levels above the drivers folder. I also tried to set it to the edk_user_repository but got an error message saying system.make:215: *** multiple target patterns. Stop. ThanksArticle: 138221
emeb <ebrombaugh@gmail.com> wrote: > On Feb 9, 1:35 pm, John Eaton <no_s...@spam.com> wrote: > > I also tried xilprg with the same results. Glad to see that I'm not the > > only one who can't get anything to work. > We should start a "Disappointed xilprog users" support group. :) > Ideally the thing to do would be to figure out the USB commands sent > to the cable by means of a USB snooper while running the Digilent > tools under WinXP. Reverse engineering the protocol should be fairly > easy from there. This would also allow one to add support for this > cable to the urJTAG suite which seems to be the most active open > source JTAG tool out there. I have worked further on xc3sprog. It runs with DLC5, Byteblaster, FT2232 and FX2, wired like in XGUFF and the USRP firmware slightly modified in the I2C section. Parallel port access is via parport on UNIX and VDMLPT1 on win32 (untested). USB transfers tries to avoid fragmentation and in the cases tested faster than the parallelport version. FT2232 can use libftd2xx and should run on win32 too. FX2 needs libusb. If anybody can provide me with a sample of FT2232H, I will add it too. I expect the FT2232H to be amazingly fast... Some code for XC95XL is added, tested with the XC95144XL, but no CPLD size detection yet. There is a command option to verify Platform Flash/CPLD. The Xilinx 1532 BSDL files where of some help, and pusblished naxjp code. There is a local CVS tree, from the last tar version from sourceforge, incorporation the pending patches up to the present state. Anybody knows how to takeover the sourceforge xc3sprog project? I have put my tarred svn trunk as patch on sourceforge, but downloader are requested to give feedback, best in the form of patches. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 138222
On Feb 8, 12:02=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > hi comp.arch.fpga, > (accidentally posted to comp.lang.vhdl > a few moments ago- sorry) > > The question - repeated after the explanation - > is: here's what I think is a nifty trick; has > anyone seen it, or been aware of it, before? > I can't believe it's really new. > > I have been messing around with baud rate generators > and suchlike - creating a pulse that's active for > one clock period at some required repetition rate - > and wanted to try a phase accumulator technique > instead of a simple divider. =A0That makes it far > easier to specify the frequency - it's simply the > phase-delta input value - and easily allows for > non-integral divide ratios, at the cost of one > master clock period of jitter. > > The phase-accumulator produces pulses with a > repetition rate of > =A0 Fc * M / N > where Fc is the master clock, M is the phase delta > and N is the counter's modulus. =A0However, to get > the huge convenience of specifying M as the required > frequency, I must make N be equal to the frequency > of Fc, and this is unlikely to be an exact power of 2. > So the phase accumulator works like this: > > =A0 on every clock pulse... > =A0 =A0 if (acc < 0) then > =A0 =A0 =A0 add :=3D acc + N; > =A0 =A0 =A0 output_pulse <=3D '1'; > =A0 =A0 else > =A0 =A0 =A0 output_pulse <=3D '0'; > =A0 =A0 end if; > =A0 =A0 acc :=3D acc - M; =A0-- unconditionally > > This is fine, but it means that on the "wrap-around" > clock cycle I must add either N-M to the accumulator; > if either M or N are variable, that costs me another > adder. > > Today I came up with an intriguing (to me) alternative: > on the wrap-around cycle, add N to the accumulator; > on the immediately subsequent cycle, add (-2M); on > all other cycles, add (-M). =A0This is of course rather > easy to do since 2M is just a left shift. =A0A few > trial synthesis runs convinced me that it will give > measurably better performance than the two-adder > version. =A0VHDL code is appended for anyone who wants > to play. > > My question is: has this trick been published anywhere? > Or is it something that "those skilled in the art" > already know about? =A0I haven't seen it before, but that > simply means I probably haven't looked hard enough. > > Thanks! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~ rate generator using novel wrap-around technique > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > library ieee; > use ieee.std_logic_1164.all; > use ieee.numeric_std.all; > > entity rate_gen is > =A0 -- Specify the master clock frequency as a generic. > =A0 generic ( ref_Hz: positive :=3D 50_000_000 ); > =A0 port > =A0 =A0 ( clock : in =A0std_logic > =A0 =A0 ; reset : in =A0std_logic =A0-- Synchronous reset. > =A0 =A0 ; rate =A0: in =A0unsigned =A0 -- Desired output frequency > =A0 =A0 ; pulse : out std_logic =A0-- The output pulse train > =A0 =A0 ); > end; > > architecture RTL of rate_gen is > begin > =A0 process (clock) > =A0 =A0 -- variable "count" is the accumulator > =A0 =A0 variable count: integer range -2**rate'length to ref_Hz-1 :=3D 0; > =A0 =A0 -- variable "overflow" is the output pulse and wraparound marker > =A0 =A0 variable overflow: std_logic :=3D '0'; > =A0 begin > =A0 =A0 if rising_edge(clock) then > =A0 =A0 =A0 if reset =3D '1' then > =A0 =A0 =A0 =A0 count :=3D 0; > =A0 =A0 =A0 =A0 overflow :=3D '0'; > =A0 =A0 =A0 elsif count < 0 then > =A0 =A0 =A0 =A0 overflow :=3D '1'; > =A0 =A0 =A0 =A0 count :=3D count + ref_Hz; > =A0 =A0 =A0 elsif overflow =3D '1' then > =A0 =A0 =A0 =A0 overflow :=3D '0'; > =A0 =A0 =A0 =A0 count :=3D count - (to_integer(rate) * 2); > =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 overflow :=3D '0'; > =A0 =A0 =A0 =A0 count :=3D count - to_integer(rate); > =A0 =A0 =A0 end if; > =A0 =A0 =A0 pulse <=3D overflow; > =A0 =A0 end if; > =A0 end process; > end; > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Did you see this thread on comp.lang.verilog? http://groups.google.com/group/comp.lang.verilog/browse_frm/thread/7cedbaf9= bdd6f1ad?hl=3Den#Article: 138223
On Feb 9, 3:12=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > I have worked further on xc3sprog. It runs with DLC5, Byteblaster, FT2232 > and FX2, wired like in XGUFF and the USRP firmware slightly modified in t= he > I2C section. Parallel port access is via parport on UNIX and VDMLPT1 on > win32 (untested). USB transfers tries to avoid fragmentation and in the > cases tested faster than the parallelport version. FT2232 can use libftd2= xx > and should run on win32 too. FX2 needs libusb. If anybody can provide me > with a sample of FT2232H, I will add it too. I expect the FT2232H to be > amazingly fast... Sorry I didn't look more closely at your contributions - I'll do that. FWIW, the Digilent USB<->JTAG cable apparently uses a CY7C68013 which is compatible with the FX2. I wonder if it would work with your code? EricArticle: 138224
emeb <ebrombaugh@gmail.com> wrote: ... > Sorry I didn't look more closely at your contributions - I'll do that. The upload was quite recent.. > FWIW, the Digilent USB<->JTAG cable apparently uses a CY7C68013 which > is compatible with the FX2. I wonder if it would work with your code? The cable driver only needs to implement void txrx_block(const unsigned char *tdi, unsigned char *tdo, \ int length, bool last); void tx_tms(unsigned char *pat, int length); to export to the higher levels. For the FX2 USRP/XGUFF cable I reused the I2C command request with using addresses above 0x7f for the JTAG requests. I2C only used 7 bit addresse, so these addresses are unused. As FX2 command transfers only have a 64 byte buffer, this is not the fastest transfer rates possible. I have uploaded to sourceforge the code snipplets implementing the needed transfers. If you have not worked before with the FX2, the learning curve is quite steep. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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