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
On Mon, 21 Jul 2008 21:27:37 -0700 (PDT), cs_posting@hotmail.com wrote: >On Jul 21, 1:45 pm, rickman <gnu...@gmail.com> wrote: > >> I don't remember for sure what the basis of 44100 Hz was, but I think >> it has to do with being compatible with TV scan rates. It is >> divisible by both 50 Hz and 60 Hz. But then so is 48,000 Hz. 44100 > >The wikipedia article on CD's suggests that it comes from the early >practice of using PCM converters to store/master digital audio on >professional video cassette decks before the later arrival of purpose >built digital audio tape equipment. They could store three stereo >samples per video line, and somehow that gets you 44100 on a PAL >recorder. And a practically identical rate on 60Hz NTSC. But since NTSC (for VCRs anyway, I can't remember if the same is true of broadcast) ran at 59.94Hz to reduce interference from 60 Hz mains, American versions of the digital audio tape systems ran at 44.056 kHz. I don't think the latter rate was ever implemented on CD. - BrianArticle: 134026
On 22 Lip, 13:03, Newman <newman5...@yahoo.com> wrote: > On Jul 22, 6:32 am, wojtek <wojtekpowiertow...@gmail.com> wrote: > > > >A better design would use clk here > > >and make baudTick a clock enable. > > > @ Mike: I'm afraid it wouldn't work, I'm not sure if you get how the > > phase accumulator works, trust me it is ok the way it is. > > I suspect Mike knows how a phase accumulator works. The rising edge > of the phase accumulator can be detected without having it be a clock > input. Some people cringe when they see a register output used as an > input clock to other synchronous logic and will go to great lengths to > avoid it because they might have to explain why this will never cause > a timing issue. In general, I would not easily discount what Mike has > to say IMHO. You got me wrong, I don't discount Mike's suggestions (I am very sorry Mike if you get the impression). Just in this case, the aim of phase accumulator is to create a clock, and using MSB of phaseAcc as clock enable would cause the UART to work with clk frequency not with the baudTick frequency. Since most DCM's aren't able to create a frequency of less than 10MHz, using phase accumulator to do it is pretty good idea (and it will be quite precise as well).Article: 134027
mike wrote:
>>>> A better design would use clk here
>>>> and make baudTick a clock enable.
wojtek wrote:
>>> @ Mike: I'm afraid it wouldn't work, I'm not sure if you get how the
>>> phase accumulator works, trust me it is ok the way it is.
I get the phase accumulator,
but why bother with the fussy DCM at all?
Newman wrote:
>> Some people cringe when they see a register output used as an
>> input clock to other synchronous logic and will go to great lengths to
>> avoid it because they might have to explain why this will never cause
>> a timing issue.
I avoid it because
I prefer writing code
to writing clock domain constraints.
> Since most DCM's aren't able to create a frequency
> of less than 10MHz, using phase accumulator to do it is pretty good
> idea (and it will be quite precise as well).
I agree.
So why did you punt it?
A phase accumulator is portable, flexible and a precise as I need.
See also:
http://groups.google.com/groups/search?q=accum_s
-- Mike Treseler
Article: 134028Hi I was looking for voltage regulator which would give me 1.2 V output voltage to power my FPGA, but still have not found. All voltage regulators, eg LM317 gives min output 1.25 - would it be healthy to power FPGA with that voltage ? or maybe voltage should be strictly 1.2 V. In datasheet max Vccint is 1.32 V, so im asking people who had an expirence with powering FPGA. I could of course use TPS75003, but it would rather like voltage regulator being used. Another thing is availabilty - LM317 is free to get, when TPS is high-cost comparnig to LM etc etc. wjArticle: 134029
Hello Paco, With the new code you post I think the problem is the same. The problem is not only the time spent in context switch, also the time in system calls is important: pthread_create and pthread_join are both system calls that will spent many cycles running with interrupts disabled (can't guess how many, but probably equal or more than a context switch, you can measure it with another timer if you are interested in the exact time it's spent). If you are interested in measuring the time some functions spent, I recommend you to use another timer and not to use the xget_clocks_ticks(). If you use another timer, you can use it to count exact cycles a function call spends, instead making 100000 calls and calculating the mean time. Answering your questions: "Is too heavy the context switch in Xilkernel?" I think it is not too heavy. I have studied the code and it's quite optimal. If you are interested I can measure how many cycles it spends. "Is the context switch done with interrupts disabled?" Yes. A context switch can be reachead by two ways: a timer interrupt, or a system call like yield(), pthread_join(), pthread_exit(), etc. In both situations the interrupts are disabled. Best regards, Pablo H PD. Saludos a Pablo. Cualquier cosa que pueda ayudar no dudes en preguntar.Article: 134030
wojjed@gmail.com wrote: > I was looking for voltage regulator which would give me 1.2 V output > voltage to power my FPGA, but still have not found. All voltage > regulators, eg LM317 gives min output 1.25 - would it be healthy to > power FPGA with that voltage ? or maybe voltage should be strictly 1.2 > V. In datasheet max Vccint is 1.32 V, so im asking people who had an > expirence with powering FPGA. I could of course use TPS75003, but it > would rather like voltage regulator being used. Another thing is > availabilty - LM317 is free to get, when TPS is high-cost comparnig to > LM etc etc. I would use something which is recommended from the manufacturers. E.g. for Altera devices, there are some information from ST: http://dkc3.digikey.com/PDF/Marketing/FPGA_Altera.pdf TPS75003, from TI, is available, too, and doesn't cost that much: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=296-17835-1-ND Linear Technology has some recommendations, too, for FPGAs: http://www.linear.com/designtools/reference_design/Product_Guide_Xilinx.pdf http://www.linear.com/designtools/reference_design/Product_Guide_Altera.pdf -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 134031
wojjed@gmail.com pisze: > Hi > > I was looking for voltage regulator which would give me 1.2 V output > voltage to power my FPGA, but still have not found. All voltage > regulators, eg LM317 gives min output 1.25 - would it be healthy to > power FPGA with that voltage ? or maybe voltage should be strictly 1.2 > V. In datasheet max Vccint is 1.32 V, so im asking people who had an > expirence with powering FPGA. I could of course use TPS75003, but it > would rather like voltage regulator being used. Another thing is > availabilty - LM317 is free to get, when TPS is high-cost comparnig to > LM etc etc. > > wj Hi, I'm using with success low drop version of LM317 - LM1117 with output voltage set to 1.25 with FPGA Cyclon II ( 1.2 V power supply ) I have running over 100 modules with such power reg. and evrything works properly. Adam GórskiArticle: 134032
On Jul 22, 9:43=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> mike wrote:
> >>>> A better design would use clk here
> >>>> and make baudTick a clock enable.
> wojtek wrote:
> >>> @ Mike: I'm afraid it wouldn't work, I'm not sure if you get how the
> >>> phase accumulator works, trust me it is ok the way it is.
>
> I get the phase accumulator,
> but why bother with the fussy DCM at all?
>
> Newman wrote:
> >> Some people cringe when they see a register output used as an
> >> input clock to other synchronous logic and will go to great lengths to
> >> avoid it because they might have to explain why this will never cause
> >> a timing issue. =A0
>
> I avoid it because
> I prefer writing code
> to writing clock domain constraints.
>
> > Since most DCM's aren't able to create a frequency
> > of less than 10MHz, using phase accumulator to do it is pretty good
> > idea (and it will be quite precise as well).
>
> I agree.
> So why did you punt it?
> A phase accumulator is portable, flexible and a precise as I need.
> See also:http://groups.google.com/groups/search?q=3Daccum_s
>
> =A0 =A0 =A0 =A0 -- Mike Treseler
Hi Wojtek
I noted with "-- Look Here ZZZ" comments where preliminary changes
could be
investigated to eliminate a clock domain. baudTick becomes a
synchronously delayed
version of phaseAcc(phaseAccWidth) and can be used to detect the
rising edge of
phaseAcc(phaseAccWidth) after a clock cycle delay. I did not
simulate it or anything.
-- baud generator based on phase accumulator
baudTickGen : process (clk) is begin
if(rising_edge(clk))then
phaseAcc <=3D phaseAcc + phaseAccTuning;
baudTick <=3D phaseAcc(phaseAccWidth); -- Look Here ZZZ
end if;
end process baudTickGen;
-- MSB of phase accumulator generates the proper baud rate
-- Look Here ZZZ baudTick <=3D phaseAcc(phaseAccWidth);
-- transmitter: 8 bits of data, no parity control, 1 stop bit
-- Look Here ZZZ transmitter : process (baudTick) is begin
transmitter : process (clk) is begin -- Look Here
-- Look HereZZZ if(rising_edge(baudTick))then
if((baudTick =3D '0') and (phaseAcc(phaseAccWidth) =3D '1')) then --
Look Here ZZZ
showtick <=3D'1';
if(reset =3D '1')then
state <=3D 0;
dataBuffer <=3D (others =3D> '0');
else
if(state =3D 0 and startTxD =3D '0')then
busyTxD <=3D '0';
TxD <=3D '1';
elsif(state =3D 0 and startTxD =3D '1')then
TxD <=3D '0';
dataBuffer <=3D dataTxD;
busyTxD <=3D '1';
state <=3D state + 1;
elsif(state > 0 and state < 9)then
busyTxD <=3D '1';
TxD <=3D dataBuffer(state-1);
state <=3D state + 1;
elsif(state =3D 9)then
TxD <=3D '1';
busyTxD <=3D '1';
state <=3D 0;
end if;
end if;
end if;
end process;
end TxD_arch;
Article: 134033On Jul 22, 11:00=A0am, Newman <newman5...@yahoo.com> wrote: > On Jul 22, 9:43=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > > > > > > > mike wrote: > > >>>> A better design would use clk here > > >>>> and make baudTick a clock enable. > > wojtek wrote: > > >>> @ Mike: I'm afraid it wouldn't work, I'm not sure if you get how th= e > > >>> phase accumulator works, trust me it is ok the way it is. > > > I get the phase accumulator, > > but why bother with the fussy DCM at all? > > > Newman wrote: > > >> Some people cringe when they see a register output used as an > > >> input clock to other synchronous logic and will go to great lengths = to > > >> avoid it because they might have to explain why this will never caus= e > > >> a timing issue. =A0 > > > I avoid it because > > I prefer writing code > > to writing clock domain constraints. > > > > Since most DCM's aren't able to create a frequency > > > of less than 10MHz, using phase accumulator to do it is pretty good > > > idea (and it will be quite precise as well). > > > I agree. > > So why did you punt it? > > A phase accumulator is portable, flexible and a precise as I need. > > See also:http://groups.google.com/groups/search?q=3Daccum_s > > > =A0 =A0 =A0 =A0 -- Mike Treseler > > Hi Wojtek > > =A0 I noted with "-- Look Here ZZZ" comments where preliminary changes > could be > investigated to eliminate a clock domain. =A0baudTick becomes a > synchronously delayed > version of phaseAcc(phaseAccWidth) and can be used to detect the > rising edge of > phaseAcc(phaseAccWidth) after a =A0clock cycle delay. =A0I did not > simulate it or anything. > > -- baud generator based on phase accumulator > =A0 baudTickGen : process (clk) is begin > =A0 =A0 if(rising_edge(clk))then > =A0 =A0 =A0 phaseAcc <=3D phaseAcc + phaseAccTuning; > =A0 =A0 =A0 baudTick <=3D phaseAcc(phaseAccWidth); =A0 =A0 =A0 =A0-- Look= Here ZZZ > =A0 =A0 end if; > =A0 end process baudTickGen; > =A0 -- MSB of phase accumulator generates the proper baud rate > =A0 -- Look Here ZZZ baudTick <=3D phaseAcc(phaseAccWidth); > > =A0 -- transmitter: 8 bits of data, no parity control, 1 stop bit > =A0 -- Look Here ZZZ transmitter : process (baudTick) is begin > =A0 transmitter : process (clk) is begin =A0-- Look Here > > =A0 =A0 -- Look HereZZZ =A0if(rising_edge(baudTick))then > =A0 =A0 if((baudTick =3D '0') and (phaseAcc(phaseAccWidth) =3D '1')) then= =A0 -- > Look Here ZZZ > =A0 =A0 =A0 =A0 showtick <=3D'1'; > =A0 =A0 =A0 if(reset =3D '1')then > =A0 =A0 =A0 =A0 state <=3D 0; > =A0 =A0 =A0 =A0 dataBuffer <=3D (others =3D> '0'); > =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 if(state =3D 0 and startTxD =3D '0')then > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '0'; > =A0 =A0 =A0 =A0 =A0 TxD <=3D '1'; > =A0 =A0 =A0 =A0 elsif(state =3D 0 and startTxD =3D '1')then > =A0 =A0 =A0 =A0 =A0 TxD <=3D '0'; > =A0 =A0 =A0 =A0 =A0 dataBuffer <=3D dataTxD; > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '1'; > =A0 =A0 =A0 =A0 =A0 state <=3D state + 1; > =A0 =A0 =A0 =A0 elsif(state > 0 and state < 9)then > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '1'; > =A0 =A0 =A0 =A0 =A0 TxD <=3D dataBuffer(state-1); > =A0 =A0 =A0 =A0 =A0 state <=3D state + 1; > =A0 =A0 =A0 =A0 elsif(state =3D 9)then > =A0 =A0 =A0 =A0 =A0 TxD <=3D '1'; > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '1'; > =A0 =A0 =A0 =A0 =A0 state <=3D 0; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 end if; > > =A0 =A0 =A0 =A0 =A0end if; > =A0 end process; > > end TxD_arch;- Hide quoted text - > > - Show quoted text - -- forgot if(rising_edge(clk))then stuff in transmitter processArticle: 134034
"John_H" <newsgroup@johnhandwork.com> wrote in message news:_YWdnayv8cLc0RjVnZ2dnUVZ_ojinZ2d@comcast.com... > > I would respectfully disagree that some hand routing is a complete waste > of energy. When RPMs or explicitly placed logic elements become useful > because of performance needs, one simple step further is to use manual > routing constraints - "directed routing" - that are included in the UCF > (user constraints file). > > > - John_H ^^ What he said. Syms.Article: 134035
tgau3qk4@gmail.com wrote: > As an intellectual exercise I have been playing with some > cryptographic functions. Currently, I am looking at the RC5 “key > expander” (http://people.csail.mit.edu/rivest/Rivest-rc5.pdf): > > A' = (S + A + B) rol 3 > B' = (L + A' + B) rol (A'+B) > > where “rol” denotes rotate left and all variables are 32-bit. > > While simple enough, I have had hard time to implement this > efficiently. My current best implementation requires >300 LUTs and >> 128 regs :( > > Can anybody help me understand how to optimize this simple function > for time and area? I am working under the following assumptions: > 1.the target is an Cyclone II FPGA (which according to Ray the suck at > arithmetic, this makes this exercise even more interesting...) > 2.The latency is two cycles (i.e. A, B, S & L are asserted at clk=t, > A' and B' are read at clk=t+2). I could go with three cycles, but I'm > not sure it does any good. > 3.S and L could be re-timed, that is, they could be available before > or after clk=t if needed (for L, it is preferred to come earlier). > 4.I am using the webpack (the $$$ version can optimize the pipeline > automatically). > 5.There is an special case where S is a constant, this could maybe > allow some optimization? > > > > Could anyone help me improve my implementation? > > > PS. Please understand that this is an intellectual exercise and not > someones school assignment, hence I prefer a good discussion instead > of your code :) If you can stand the latency, you can make the circuit pretty small. You can use an ALU-type structure with just a single adder, saving gates. The rol will be larger if implemented as a barrel shifter, but if you make a 1-bit rol and use a counter loaded with (A'+B) to control it, the logic will be minimal, but the latency as large as 32 cycles. -KevinArticle: 134036
Hello All.
Can anyone tell me the Push buttons ,leds names that i can write
in the constraint file for Virtex -4.
Any code that helps me test the functionality of virtex 4 will be
appreciated.
Article: 134037>explore wrote: >> Thanks for your response. Unfortunately the board was not designed >> by us. This is an AVNET PCIe board that we happened to purchase a >> while ago. We hadn't put in the XAUI core until recently. Now we are >> forced to use the same GTP locations specified in the AVNET user >> guide. We were suggested by Xilinx support that we can use the >> flexibility of channel bonding available with rocketio's to try and >> make timing and this is the reason we are still hopeful of finding a >> solution to it. They also told us that some people were successful in >> making changes to the channel bonding in AURORA cores and the design >> to meet timing when they had a similar problem. As I mentioned >> earlier, the design meets timing when the tiles have channel bonding >> levels of 5,4,1,0 with 2 pipeline stages for rxchanbond signals, but I >> do not get to see it work in simulation. Would like your suggestion/ >> inputs on this. >> >> Thanks for your time once again. >> >> --Chethan >> >> >> On Jun 16, 7:31 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >>> explore wrote: >>>> I am using a XAUI core in my design for a PCIe board with a Xilinx >>>> Virtex - 5 LX110t FPGA. The board specifications require the GTP dual >>>> tiles of XAUI to be constrained to locations X0Y0 and X0Y7 which are >>>> far from each other on the FPGA. Due to this, the design does not meet >>>> timing. The user-guide for the rocketio transceivers suggests >>>> modification of channel bonding attributes of the GTP Dual tiles to >>>> meet timing. To try this out, the default channel bonding level for >>>> the 4 GTP tiles (2 GTP duals) was changed to 3,2,1,0 with 3 as the >>>> master tile. This design works fine in simulation, but does not meet >>>> timing. The timing error as seen on timing analyzer was due to the >>>> rxchanbondo signal. >>>> The channel bond level was further changed to 5,4,1,0 with 5 as the >>>> master. Two pipeline stages were added for the rxchanbondo signal >>>> (between the tiles 4 and 1). This design meets timing, but does not >>>> work in simulation. All these changes were made to the >>>> rocketio_wrapper.v file in the XAUI core generated using coregen. >>>> I feel that the wiring between the tiles in the rocketio_wrapper.v >>>> file needs to be modified to hook-up all the signals that may have >>>> been disturbed due to the addition of the two pipeline stages. >>>> Unfortunately I do not have a lot of experience working with rocketio >>>> transceivers and their channel bonding attributes which puts me in a >>>> state of bother while analyzing what signals need to be modified/ >>>> reassigned/patched between the gtp tiles. >>>> I would appreciate any suggestions from anybody who has had experience >>>> working with XAUI, rocketio's and their channel bonding attributes. >>>> Thanks for your help in advance >>> Why are the GTP_DUAL sites constrained to X0Y0 and X0Y7, these are the >>> worst possible locations to choose from. If the board hasn't gone >>> through layout yet, can you change these to be adjacent locations? >>> >>> Ed McGettigan >>> -- >>> Xilinx Inc. >> > >Ok, I understand now. I hope that when you take the design forward to >your own platform that you clean this up and don't follow this design. > >I was not familiar with this particular board, but I was able to >determine that you are using the Avnet AES-XLX-V5LXT-PCIE110-G board and >after getting the schematics it does show that the XAUI/CX4 interface >that you are trying to use is split across the device using X0Y0 and X0Y7. > >There are a couple of issues with this board design, but I will address >your channel bond timing issue first. > >You can make this timing work, but you have to insert additional >registers in the RXCHBONDO[2:0] to RXCHBONDI[2:0] path. These ports use >the faster 10-bit RXUSRCLK clock that will be running at at 312.5MHz in >your application. My guess is that you will need at least 2 register >stages to get across the device at this frequency and you made need >three as the clock-to-out on RXCHBONDO and the setup into RXCHBONDI are >long with respect to a 312.5 MHz clock. > >You should place absolute placement LOC attributes on these registers to >ensure that MAP doesn't pack the stages into the same slice and you get >the spread that you need. After you have the timing working you will >then need to set the correct CHAN_BOND_LEVEL value for each lane based >on the number of stages that you used. This is describe in the GTP User >Guide (UG196) Configurable Channel Bonding section. > >In addition to channel bonding issue you also have two other issues with >this board that impact your XAUI design. > >1) You need to use two REFCLK sources, one for each GTP_DUAL. The board >supports it, but you will likely need to update the XAUI source to add >the second set of inputs to one of the GTP_DUALs. > >2) The P/N nets are swapped for some of the pairs. The schematic >indicates that you need to set the TXPOLARITY0 and RXPOLARITY0 on X0Y7 >and TXPOLARITY1 on X0Y0 to 1 (default is 0). > >Good luck. > >Ed McGettigan >-- >Xilinx Inc. > Does this help resolve issues? Do you see any other issues with this board?Article: 134038
>Hello Paco, > >With the new code you post I think the problem is the same. >The problem is not only the time spent in context switch, also the >time in system calls is important: pthread_create and pthread_join are >both system calls that will spent many cycles running with interrupts >disabled (can't guess how many, but probably equal or more than a >context switch, you can measure it with another timer if you are >interested in the exact time it's spent). >If you are interested in measuring the time some functions spent, I >recommend you to use another timer and not to use the >xget_clocks_ticks(). If you use another timer, you can use it to count >exact cycles a function call spends, instead making 100000 calls and >calculating the mean time. > >Answering your questions: >"Is too heavy the context switch in Xilkernel?" I think it is not too >heavy. I have studied the code and it's quite optimal. If you are >interested I can measure how many cycles it spends. >"Is the context switch done with interrupts disabled?" Yes. A context >switch can be reachead by two ways: a timer interrupt, or a system >call like yield(), pthread_join(), pthread_exit(), etc. In both >situations the interrupts are disabled. > >Best regards, > >Pablo H > >PD. Saludos a Pablo. Cualquier cosa que pueda ayudar no dudes en >preguntar. > Pablo, I appreciate very much your advices. I will try to use another timer as you point out. Saludos, PacoArticle: 134039
On 22 Jul, 17:41, "saad" <saad.m...@yahoo.com> wrote: > Hello All. > =A0 =A0 =A0 =A0 =A0 Can anyone tell me the Push buttons ,leds names that = i can write > in the constraint file for Virtex -4. > Any code that helps me test the functionality of virtex 4 will be > appreciated. Which PCB are you using?Article: 134040
Hello, In Xilinx WebPACK 10.1 (possibly with 10.1 SP2 June 2008 - I can not remember whether I actually installed that), pasting sometimes works properly; sometimes does not paste to where the cursor is; and sometimes pastes to the beginning of the file even when that is not where the cursor is (or today instead, to the end of the file, even when that is not where the cursor is). Often a combination of the aforementioned outcomes happen to me. I tend to prefer to copy; paste; and cut with Ctrl-Insert; Shift-Insert; and Shift-Delete, respectively, instead of Ctrl-C; Ctrl-V; and Ctrl-X. I think that this might be related. I have not invested enough experimentation to reliably reproduce this bug, if possible. If I shall have enough time, I might do this later and submit a bug report to Xilinx if no one had done so already. Have other people experienced this bug? Regards, Colin Paul GlosterArticle: 134041
For those of you interested in research on the development of FPGA CAD
and architecture,
I am pleased to announce the release of version 5.0 of VPR, *post-
Beta*. This version contains several bug fixes on the beta version
released on Feburary 22nd, 2008, and a few features. See
http://www.eecg.utoronto.ca/vpr for the new version.
VPR is a CAD tool suite targeting hypothetical FPGA architectures that
enables both FPGA architecture and CAD exploration research. Its
primary functionality is to provide packing (clustering), placement,
routing and timing analysis for FPGA architectures described by an
architecture description file.
Building on the widely-used VPR 4.30, VPR 5.0 adds three important new
features:
1. Single-Driver Routing Architecture (also known as Direct-Drive or
Unidirectional routing architectures) now commonly used in major
commercial FPGAs.
2. Heterogeneous logic blocks - the ability to describe different hard
blocks, in addition to the regular soft logic. A new form of
architecture description file permits this.
3. A wide range of transistor-optimized design files, spanning
architecture, different area-delay tradeoffs, and IC processes down
to 22nm, based on the Arizona PTM process models. For each logical
architecture, we provide different electrical designs modeling the
different IC
processes *and* different transistor-sizing goals with respect to the
importance of area and delay.
In addition, in an attempt to maintain VPR's legendary software
quality, we include regression tests that allow the developer the
ability to test changes for correctness and quality.
Also, we are providing an open source front-end CAD flow from Verilog
to the T-Vpack input step. It begins with ODIN (for Verilog parsing
and elaboration), passes through a modified version of Berkeley's ABC
logic synthesis (thanks to Alan Mishchenko for support of ABC) that
permits heterogenous structures to pass through, unhurt.
Download Location: http://www.eecg.utoronto.ca/vpr
The license for T-VPACK and VPR is the same as that granted
previously: non-commercial,
not-for-profit use (see the download page for details). The license of
the front-end ODIN CAD flow is open source.
We are interested to receive feedback and bug reports. Please send
those to: vpr@eecg.utoronto.ca. We also hope to engage in longer-
range improvements to this software
and are interested in suggestions on that front.
CREDITS:
In addition to the people listed above, this new release is the result
of many people's work, including the original author, Vaughn Betz, who
set a very high standard of quality that is hard to meet. Sandy
Marquardt wrote the original timing-driving packing and placement.
Andy Ye created the first version of the single-driver routing, which
Mark Fang improved. Danny Paladino's research influenced the
architecture description work incorporated here. Russ Tessier
helped begin this project when he was visiting Toronto, and Mark Fang
and Andrew Ling contributed to that early work. Ted Campbell was
instrumental in the new heterogeneous block
and routing architecture work. Ian Kuon's research and efforts
contributed the new
architecture files describing a wide range of architectures, in
different processes
and optimized for different target area and performance. Jason Luu
and Peter Jamieson
were key developers instrumental in the development and release of
this version of the software.
Jonathan Rose
-----------------------------------------------------------
Jonathan Rose, Professor and Chair
The Edward S. Rogers Sr. Department of
Electrical and Computer Engineering,
University of Toronto
10 King's College Rd,
Toronto, Ontario
CANADA M5S 3G4
-----------------------------------------------------------
Article: 134042
On 22 Jul., 17:00, Newman <newman5...@yahoo.com> wrote:
> On Jul 22, 9:43 am, Mike Treseler <mtrese...@gmail.com> wrote:
>
>
>
> > mike wrote:
> > >>>> A better design would use clk here
> > >>>> and make baudTick a clock enable.
> > wojtek wrote:
> > >>> @ Mike: I'm afraid it wouldn't work, I'm not sure if you get how the
> > >>> phase accumulator works, trust me it is ok the way it is.
>
> > I get the phase accumulator,
> > but why bother with the fussy DCM at all?
>
> > Newman wrote:
> > >> Some people cringe when they see a register output used as an
> > >> input clock to other synchronous logic and will go to great lengths to
> > >> avoid it because they might have to explain why this will never cause
> > >> a timing issue.
>
> > I avoid it because
> > I prefer writing code
> > to writing clock domain constraints.
>
> > > Since most DCM's aren't able to create a frequency
> > > of less than 10MHz, using phase accumulator to do it is pretty good
> > > idea (and it will be quite precise as well).
>
> > I agree.
> > So why did you punt it?
> > A phase accumulator is portable, flexible and a precise as I need.
> > See also:http://groups.google.com/groups/search?q=accum_s
>
> > -- Mike Treseler
>
> Hi Wojtek
>
> I noted with "-- Look Here ZZZ" comments where preliminary changes
> could be
> investigated to eliminate a clock domain. baudTick becomes a
> synchronously delayed
> version of phaseAcc(phaseAccWidth) and can be used to detect the
> rising edge of
> phaseAcc(phaseAccWidth) after a clock cycle delay. I did not
> simulate it or anything.
>
> -- baud generator based on phase accumulator
> baudTickGen : process (clk) is begin
> if(rising_edge(clk))then
> phaseAcc <= phaseAcc + phaseAccTuning;
> baudTick <= phaseAcc(phaseAccWidth); -- Look Here ZZZ
> end if;
> end process baudTickGen;
> -- MSB of phase accumulator generates the proper baud rate
> -- Look Here ZZZ baudTick <= phaseAcc(phaseAccWidth);
>
> -- transmitter: 8 bits of data, no parity control, 1 stop bit
> -- Look Here ZZZ transmitter : process (baudTick) is begin
> transmitter : process (clk) is begin -- Look Here
>
> -- Look HereZZZ if(rising_edge(baudTick))then
> if((baudTick = '0') and (phaseAcc(phaseAccWidth) = '1')) then --
> Look Here ZZZ
> showtick <='1';
> if(reset = '1')then
> state <= 0;
> dataBuffer <= (others => '0');
> else
> if(state = 0 and startTxD = '0')then
> busyTxD <= '0';
> TxD <= '1';
> elsif(state = 0 and startTxD = '1')then
> TxD <= '0';
> dataBuffer <= dataTxD;
> busyTxD <= '1';
> state <= state + 1;
> elsif(state > 0 and state < 9)then
> busyTxD <= '1';
> TxD <= dataBuffer(state-1);
> state <= state + 1;
> elsif(state = 9)then
> TxD <= '1';
> busyTxD <= '1';
> state <= 0;
> end if;
> end if;
>
> end if;
> end process;
>
> end TxD_arch;
it's been far too long since I've written any VHDL, but I verilog I
would do it like this:
reg [phaseAccWidth-1:0] phaseAcc;
reg baudTick;
always@(posedge clk or rstb)
if(!rstb)
{baudTick,phaseAcc} <= 0;
else
{baudTick,phaseAcc} <= {1'd0,phaseAcc} + phaseAccTuning;
....
-Lasse
Article: 134043
On Jul 22, 7:23=A0pm, langw...@fonz.dk wrote:
> On 22 Jul., 17:00, Newman <newman5...@yahoo.com> wrote:
>
>
>
>
>
> > On Jul 22, 9:43 am, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > > mike wrote:
> > > >>>> A better design would use clk here
> > > >>>> and make baudTick a clock enable.
> > > wojtek wrote:
> > > >>> @ Mike: I'm afraid it wouldn't work, I'm not sure if you get how =
the
> > > >>> phase accumulator works, trust me it is ok the way it is.
>
> > > I get the phase accumulator,
> > > but why bother with the fussy DCM at all?
>
> > > Newman wrote:
> > > >> Some people cringe when they see a register output used as an
> > > >> input clock to other synchronous logic and will go to great length=
s to
> > > >> avoid it because they might have to explain why this will never ca=
use
> > > >> a timing issue.
>
> > > I avoid it because
> > > I prefer writing code
> > > to writing clock domain constraints.
>
> > > > Since most DCM's aren't able to create a frequency
> > > > of less than 10MHz, using phase accumulator to do it is pretty good
> > > > idea (and it will be quite precise as well).
>
> > > I agree.
> > > So why did you punt it?
> > > A phase accumulator is portable, flexible and a precise as I need.
> > > See also:http://groups.google.com/groups/search?q=3Daccum_s
>
> > > =A0 =A0 =A0 =A0 -- Mike Treseler
>
> > Hi Wojtek
>
> > =A0 I noted with "-- Look Here ZZZ" comments where preliminary changes
> > could be
> > investigated to eliminate a clock domain. =A0baudTick becomes a
> > synchronously delayed
> > version of phaseAcc(phaseAccWidth) and can be used to detect the
> > rising edge of
> > phaseAcc(phaseAccWidth) after a =A0clock cycle delay. =A0I did not
> > simulate it or anything.
>
> > -- baud generator based on phase accumulator
> > =A0 baudTickGen : process (clk) is begin
> > =A0 =A0 if(rising_edge(clk))then
> > =A0 =A0 =A0 phaseAcc <=3D phaseAcc + phaseAccTuning;
> > =A0 =A0 =A0 baudTick <=3D phaseAcc(phaseAccWidth); =A0 =A0 =A0 =A0-- Lo=
ok Here ZZZ
> > =A0 =A0 end if;
> > =A0 end process baudTickGen;
> > =A0 -- MSB of phase accumulator generates the proper baud rate
> > =A0 -- Look Here ZZZ baudTick <=3D phaseAcc(phaseAccWidth);
>
> > =A0 -- transmitter: 8 bits of data, no parity control, 1 stop bit
> > =A0 -- Look Here ZZZ transmitter : process (baudTick) is begin
> > =A0 transmitter : process (clk) is begin =A0-- Look Here
>
> > =A0 =A0 -- Look HereZZZ =A0if(rising_edge(baudTick))then
> > =A0 =A0 if((baudTick =3D '0') and (phaseAcc(phaseAccWidth) =3D '1')) th=
en =A0 --
> > Look Here ZZZ
> > =A0 =A0 =A0 =A0 showtick <=3D'1';
> > =A0 =A0 =A0 if(reset =3D '1')then
> > =A0 =A0 =A0 =A0 state <=3D 0;
> > =A0 =A0 =A0 =A0 dataBuffer <=3D (others =3D> '0');
> > =A0 =A0 =A0 else
> > =A0 =A0 =A0 =A0 if(state =3D 0 and startTxD =3D '0')then
> > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '0';
> > =A0 =A0 =A0 =A0 =A0 TxD <=3D '1';
> > =A0 =A0 =A0 =A0 elsif(state =3D 0 and startTxD =3D '1')then
> > =A0 =A0 =A0 =A0 =A0 TxD <=3D '0';
> > =A0 =A0 =A0 =A0 =A0 dataBuffer <=3D dataTxD;
> > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '1';
> > =A0 =A0 =A0 =A0 =A0 state <=3D state + 1;
> > =A0 =A0 =A0 =A0 elsif(state > 0 and state < 9)then
> > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '1';
> > =A0 =A0 =A0 =A0 =A0 TxD <=3D dataBuffer(state-1);
> > =A0 =A0 =A0 =A0 =A0 state <=3D state + 1;
> > =A0 =A0 =A0 =A0 elsif(state =3D 9)then
> > =A0 =A0 =A0 =A0 =A0 TxD <=3D '1';
> > =A0 =A0 =A0 =A0 =A0 busyTxD <=3D '1';
> > =A0 =A0 =A0 =A0 =A0 state <=3D 0;
> > =A0 =A0 =A0 =A0 end if;
> > =A0 =A0 =A0 end if;
>
> > =A0 =A0 =A0 =A0 =A0end if;
> > =A0 end process;
>
> > end TxD_arch;
>
> it's been far too long since I've written any VHDL, but I verilog I
> would do it like this:
>
> reg =A0[phaseAccWidth-1:0] phaseAcc;
> reg =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0baudTick;
>
> always@(posedge clk or rstb)
> =A0if(!rstb)
> =A0 =A0 {baudTick,phaseAcc} <=3D 0;
> =A0else
> =A0 =A0 {baudTick,phaseAcc} <=3D {1'd0,phaseAcc} + phaseAccTuning;
>
> ....
>
> -Lasse- Hide quoted text -
>
> - Show quoted text -
Hi Lasse,
It would appear that your way is clever. It looks to generates a
clock enable pulse on the overflow which would appear to happen only
for one clk cycle, and it also has a reset which would make the
simulation a easier. Took me a minute to determine what you were
doing.
I did not mean to get involved with recoding the designer's file. I
thought there was some communications snafu of what was meant by using
baudTick as a clock enable. My attempt was to try to give a little
better understanding of what was involved and kindof show that it was
not a big change. I think your code does this better. With that, I
shall exit this thread
-Regards
Newman
-Newman
Article: 134044akshat <mailtoakshat@gmail.com> writes: > Has anyone tried to convert DVI format to BT.656? Depends on the resolution and timing of the DVI. There isn't a single "DVI format".Article: 134045
> file:///C:/Xilinx/doc/usenglish/help/delay_types/html/web_ds_v4/ta_tbxcy.htm Brilliant, thanks simon.Article: 134046
I'am always open for new ideas how to code certain things, but for now
I will probably stick with my code (since I've written small software
to automatically generate VHDL for certain input/output frequencies),
in future I will probably switch to Verilog and update files on my
page with Verilog files instead of VHDL. But such suggestions are
always helpful and welcome :)
Regards
Newman napisa=C5=82(a):
> On Jul 22, 7:23=EF=BF=BDpm, langw...@fonz.dk wrote:
> > On 22 Jul., 17:00, Newman <newman5...@yahoo.com> wrote:
> >
> >
> >
> >
> >
> > > On Jul 22, 9:43 am, Mike Treseler <mtrese...@gmail.com> wrote:
> >
> > > > mike wrote:
> > > > >>>> A better design would use clk here
> > > > >>>> and make baudTick a clock enable.
> > > > wojtek wrote:
> > > > >>> @ Mike: I'm afraid it wouldn't work, I'm not sure if you get ho=
w the
> > > > >>> phase accumulator works, trust me it is ok the way it is.
> >
> > > > I get the phase accumulator,
> > > > but why bother with the fussy DCM at all?
> >
> > > > Newman wrote:
> > > > >> Some people cringe when they see a register output used as an
> > > > >> input clock to other synchronous logic and will go to great leng=
ths to
> > > > >> avoid it because they might have to explain why this will never =
cause
> > > > >> a timing issue.
> >
> > > > I avoid it because
> > > > I prefer writing code
> > > > to writing clock domain constraints.
> >
> > > > > Since most DCM's aren't able to create a frequency
> > > > > of less than 10MHz, using phase accumulator to do it is pretty go=
od
> > > > > idea (and it will be quite precise as well).
> >
> > > > I agree.
> > > > So why did you punt it?
> > > > A phase accumulator is portable, flexible and a precise as I need.
> > > > See also:http://groups.google.com/groups/search?q=3Daccum_s
> >
> > > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD -- Mike Treseler
> >
> > > Hi Wojtek
> >
> > > =EF=BF=BD I noted with "-- Look Here ZZZ" comments where preliminary =
changes
> > > could be
> > > investigated to eliminate a clock domain. =EF=BF=BDbaudTick becomes a
> > > synchronously delayed
> > > version of phaseAcc(phaseAccWidth) and can be used to detect the
> > > rising edge of
> > > phaseAcc(phaseAccWidth) after a =EF=BF=BDclock cycle delay. =EF=BF=BD=
I did not
> > > simulate it or anything.
> >
> > > -- baud generator based on phase accumulator
> > > =EF=BF=BD baudTickGen : process (clk) is begin
> > > =EF=BF=BD =EF=BF=BD if(rising_edge(clk))then
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD phaseAcc <=3D phaseAcc + phaseAccTuning=
;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD baudTick <=3D phaseAcc(phaseAccWidth); =
=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD-- Look Here ZZZ
> > > =EF=BF=BD =EF=BF=BD end if;
> > > =EF=BF=BD end process baudTickGen;
> > > =EF=BF=BD -- MSB of phase accumulator generates the proper baud rate
> > > =EF=BF=BD -- Look Here ZZZ baudTick <=3D phaseAcc(phaseAccWidth);
> >
> > > =EF=BF=BD -- transmitter: 8 bits of data, no parity control, 1 stop b=
it
> > > =EF=BF=BD -- Look Here ZZZ transmitter : process (baudTick) is begin
> > > =EF=BF=BD transmitter : process (clk) is begin =EF=BF=BD-- Look Here
> >
> > > =EF=BF=BD =EF=BF=BD -- Look HereZZZ =EF=BF=BDif(rising_edge(baudTick)=
)then
> > > =EF=BF=BD =EF=BF=BD if((baudTick =3D '0') and (phaseAcc(phaseAccWidth=
) =3D '1')) then =EF=BF=BD --
> > > Look Here ZZZ
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD showtick <=3D'1';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD if(reset =3D '1')then
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD state <=3D 0;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD dataBuffer <=3D (others =3D> =
'0');
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD else
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD if(state =3D 0 and startTxD =
=3D '0')then
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD busyTxD <=3D '0';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD TxD <=3D '1';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD elsif(state =3D 0 and startTx=
D =3D '1')then
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD TxD <=3D '0';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD dataBuffer <=3D dat=
aTxD;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD busyTxD <=3D '1';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD state <=3D state + =
1;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD elsif(state > 0 and state < 9=
)then
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD busyTxD <=3D '1';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD TxD <=3D dataBuffer=
(state-1);
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD state <=3D state + =
1;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD elsif(state =3D 9)then
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD TxD <=3D '1';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD busyTxD <=3D '1';
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD state <=3D 0;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD end if;
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD end if;
> >
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDend if;
> > > =EF=BF=BD end process;
> >
> > > end TxD_arch;
> >
> > it's been far too long since I've written any VHDL, but I verilog I
> > would do it like this:
> >
> > reg =EF=BF=BD[phaseAccWidth-1:0] phaseAcc;
> > reg =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDbaudTick;
> >
> > always@(posedge clk or rstb)
> > =EF=BF=BDif(!rstb)
> > =EF=BF=BD =EF=BF=BD {baudTick,phaseAcc} <=3D 0;
> > =EF=BF=BDelse
> > =EF=BF=BD =EF=BF=BD {baudTick,phaseAcc} <=3D {1'd0,phaseAcc} + phaseAcc=
Tuning;
> >
> > ....
> >
> > -Lasse- Hide quoted text -
> >
> > - Show quoted text -
>
> Hi Lasse,
> It would appear that your way is clever. It looks to generates a
> clock enable pulse on the overflow which would appear to happen only
> for one clk cycle, and it also has a reset which would make the
> simulation a easier. Took me a minute to determine what you were
> doing.
>
> I did not mean to get involved with recoding the designer's file. I
> thought there was some communications snafu of what was meant by using
> baudTick as a clock enable. My attempt was to try to give a little
> better understanding of what was involved and kindof show that it was
> not a big change. I think your code does this better. With that, I
> shall exit this thread
>
> -Regards
>
> Newman
>
> -Newman
Article: 134047
hmm
I'm getting quite puzzled over this... I've set all my values for
simulation, for my INOUT ports, sender_BUS to be 11111 at
modelsim..but when I run it, my 'outtest' which is supposed to go high
is 'U' instead.
Am I using INOUT the wrong way?
====================================================================
entity sender is
Port ( sender_BUS : inout STD_LOGIC_VECTOR (4 downto 0);
outtest: OUT STD_LOGIC;
sender_CLK : in STD_LOGIC);
end sender;
process(sender_CLK)
begin
if(sender_BUS(4 downto 0) = "11111") then
outtest<='1';
end if;
end process;
Article: 134048"Zhane" <me75@hotmail.com> wrote in message news:68049ba2-0c7a-498e-857b-b951b2a2eef8@z11g2000prl.googlegroups.com... > hmm > > I'm getting quite puzzled over this... I've set all my values for > simulation, for my INOUT ports, sender_BUS to be 11111 at > modelsim..but when I run it, my 'outtest' which is supposed to go high > is 'U' instead. > > Am I using INOUT the wrong way? > ==================================================================== > entity sender is > Port ( sender_BUS : inout STD_LOGIC_VECTOR (4 downto 0); > outtest: OUT STD_LOGIC; > sender_CLK : in STD_LOGIC); > end sender; > > process(sender_CLK) process(sender_BUS) Hans www.ht-lab.com if(sender_BUS > begin > if(sender_BUS(4 downto 0) = "11111") then > outtest<='1'; > > end if; > end process;Article: 134049
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
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