Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 134025

Article: 134025
Subject: Re: audio serial port i2s
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 22 Jul 2008 12:23:46 +0100
Links: << >>  << T >>  << A >>
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.

- Brian


Article: 134026
Subject: Re: Help to SImulate Uart TX
From: wojtek <wojtekpowiertowski@gmail.com>
Date: Tue, 22 Jul 2008 04:29:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Help to SImulate Uart TX
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 22 Jul 2008 06:43:08 -0700
Links: << >>  << T >>  << A >>
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: 134028
Subject: powering fpga with lm317
From: wojjed@gmail.com
Date: Tue, 22 Jul 2008 06:45:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 134029
Subject: Re: Strange behaviour with Xilkernel
From: Pablo H <pablo.huerta@gmail.com>
Date: Tue, 22 Jul 2008 07:03:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: powering fpga with lm317
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 22 Jul 2008 16:14:18 +0200
Links: << >>  << T >>  << A >>
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.de

Article: 134031
Subject: Re: powering fpga with lm317
From: =?ISO-8859-1?Q?Adam_G=F3rski?= <totutousungorskia@malpawp.pl>
Date: Tue, 22 Jul 2008 16:17:50 +0200
Links: << >>  << T >>  << A >>
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órski

Article: 134032
Subject: Re: Help to SImulate Uart TX
From: Newman <newman5382@yahoo.com>
Date: Tue, 22 Jul 2008 08:00:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 134033
Subject: Re: Help to SImulate Uart TX
From: Newman <newman5382@yahoo.com>
Date: Tue, 22 Jul 2008 08:20:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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 process

Article: 134034
Subject: Re: Xilinx FPGA editor tips?
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 22 Jul 2008 16:22:14 +0100
Links: << >>  << T >>  << A >>

"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
Subject: Re: help me improve this simple function
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Tue, 22 Jul 2008 10:41:02 -0600
Links: << >>  << T >>  << A >>
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.
-Kevin

Article: 134036
Subject: help needed for Virtex-4
From: "saad" <saad.mian@yahoo.com>
Date: Tue, 22 Jul 2008 11:41:07 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: XAUI v7.2 - timing issue - *channel bonding attributes*
From: "jaink" <kamalj@gmail.com>
Date: Tue, 22 Jul 2008 11:41:28 -0500
Links: << >>  << T >>  << A >>
>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
Subject: Re: Strange behaviour with Xilkernel
From: "FJ.Perogil" <pperogil@gmail.com>
Date: Tue, 22 Jul 2008 11:41:43 -0500
Links: << >>  << T >>  << A >>
>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,
Paco



Article: 134039
Subject: Re: help needed for Virtex-4
From: Jon Beniston <jon@beniston.com>
Date: Tue, 22 Jul 2008 09:44:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Anomalous pasting in Xilinx WebPACK 10.1
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Tue, 22 Jul 2008 18:34:31 +0100
Links: << >>  << T >>  << A >>
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 Gloster

Article: 134041
Subject: New Release of VPR Version 5.0 (non-Beta)
From: JonathanScottRose@gmail.com
Date: Tue, 22 Jul 2008 14:38:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Help to SImulate Uart TX
From: langwadt@fonz.dk
Date: Tue, 22 Jul 2008 16:23:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Help to SImulate Uart TX
From: Newman <newman5382@yahoo.com>
Date: Tue, 22 Jul 2008 17:45:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 134044
Subject: Re: DVI to BT.656
From: Eric Smith <eric@brouhaha.com>
Date: Tue, 22 Jul 2008 18:13:15 -0700
Links: << >>  << T >>  << A >>
akshat <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
Subject: Re: Xilinx timing parameter definitions? e.g. Tbxcy, Tcinck, etc?
From: Andrew FPGA <andrew.newsgroup@gmail.com>
Date: Tue, 22 Jul 2008 22:47:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
> file:///C:/Xilinx/doc/usenglish/help/delay_types/html/web_ds_v4/ta_tbxcy.htm
Brilliant, thanks simon.




Article: 134046
Subject: Re: Help to SImulate Uart TX
From: wojtek <wojtekpowiertowski@gmail.com>
Date: Tue, 22 Jul 2008 22:54:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Modelsim Simulate INOUT port
From: Zhane <me75@hotmail.com>
Date: Wed, 23 Jul 2008 00:26:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Modelsim Simulate INOUT port
From: "HT-Lab" <hans64@ht-lab.com>
Date: Wed, 23 Jul 2008 09:08:43 +0100
Links: << >>  << T >>  << A >>

"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
Subject: icap Xwicap_DeviceRead problems
From: lixia.rem@gmail.com
Date: Wed, 23 Jul 2008 01:34:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search