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 161350

Article: 161350
Subject: Re: Field update
From: polovnikov.rtf@gmail.com
Date: Fri, 19 Apr 2019 01:15:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
=D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 19 =D0=B0=D0=BF=D1=80=D0=B5=D0=
=BB=D1=8F 2019 =D0=B3., 9:02:21 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Julio Di Egidio =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:
> On Thursday, 18 April 2019 12:38:42 UTC+2, polovn...@gmail.com  wrote:
> > =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 21 =D0=BE=D0=BA=D1=82=D1=8F=
=D0=B1=D1=80=D1=8F 2008 =D0=B3., 6:40:26 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Bryan =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:
> > > I think the MultiBoot feature available in Xilinx FPGAs is especially
> > > useful for field updates.  MultiBoot allows you to update the FPGA
> > > while maintaining a failsafe image.  Avnet has an example application
> > > note showing how to do this, updating the secondary image in serial
> > > Flash with a new image arriving over ethernet.
> > >=20
> > > "S3A1800DSP Serial Flash Bistream Update over Ethernet" at
> > > https://www.em.avnet.com/common/filetree/0%2C2740%2CRID%3D&CID%3D4210=
6&CCD%3DUSA&SID%3D32214&DID%3DDF2&SRT%3D1&LID%3D32232&PRT%3D0&PVW%3D&PNT%3D=
&BID%3DDF2&CTP%3DEVK%2C00.html?ACD=3D3
> > >=20
> > > Bryan
> > >=20
> > > On Oct 19, 9:25=C2=A0am, Jan <1...@2.3> wrote:
> > > > Dear all,
> > > >
> > > > What are the smartest way to make a solo FPGA project capable of fi=
eld
> > > > updates? I'm very new in the FPGA world so I don't much about the
> > > > practical use of them. Normally when I uses microcontrollers I make=
 them
> > > > updateble via USB, serial or SD cards.
> > > >
> > > > What techniques are possible when I want to avoid having a uP in th=
e
> > > > project.
> > > >
> > > > My target is a Xilinx Spartan 3A or 3AN
> >=20
> > Hi, nobody knows, how to get this reference design. The link doesn't wo=
rk
>=20
> I have simply searched for "S3A1800DSP Serial Flash Bistream Update over
> Ethernet", here is the first result I get:
>=20
> <https://forums.xilinx.com/t5/Embedded-Development-Tools/Bootloader-for-S=
partan-6-with-SPI-FLash/td-p/158360>
>=20
> That said, it is very bad etiquette to resurrect old threads: open a new =
one,
> possibly with links to any old posts or whatever is relevant...
>=20
> HTH and good luck,
>=20
> Julio

I also found this topic on the forum. Unfortunately, all links related to t=
his project do not work.

Article: 161351
Subject: Up/Down Binary Counter with Dynamic Count-to Flag
From: buse.victorstefan@decathlon.com
Date: Sun, 21 Apr 2019 15:39:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
hello, i need to solve this problem in verilog:Up/Down Binary Counter with Dynamic Count-to Flag 
  
this is start cod: 


module DW03_bictr_dcnto_inst( inst_data, inst_count_to, inst_up_dn, 
inst_load, inst_cen, inst_clk, inst_reset, count_inst, tercnt_inst ); 
parameter width = 8; 
input [width-1 : 0] inst_data; 
input [width-1 : 0] inst_count_to; 
input inst_up_dn; 
input inst_load; 
input inst_cen; 
input inst_clk; 
input inst_reset; 
output [width-1 : 0] count_inst; 
output tercnt_inst; 
// Instance of DW03_bictr_dcnto 
DW03_bictr_dcnto #(width) 
U1 ( .data(inst_data), .count_to(inst_count_to), .up_dn(inst_up_dn), 
.load(inst_load), .cen(inst_cen), .clk(inst_clk), 
.reset(inst_reset), .count(count_inst), .tercnt(tercnt_inst) ); 
endmodule 


i already have: test.v 

module DW03_bictr_dcnto_inst( inst_data, inst_count_to, inst_up_dn, 
inst_load, inst_cen, inst_clk, inst_reset, count_inst, tercnt_inst ); 
parameter width = 8; 
input [width-1 : 0] inst_data; 
input [width-1 : 0] inst_count_to; 
input inst_up_dn; 
input inst_load; 
input inst_cen; 
input inst_clk; 
input inst_reset; 
output [width-1 : 0] count_inst; 
output tercnt_inst; 
// Instance of DW03_bictr_dcnto 
always @(posedge inst_clk or negedge inst_reset) 
    if (~inst_reset) begin 
                      count_inst<={width{4'b0000}}; 
                 end 
        else begin 
                 if(~inst_load) begin 
                                  count_inst<=inst_data; 
                                end 
                     else begin 
                              if (inst_cen) begin 
                                if (inst_up_dn) begin 
                                  count_inst<=count_inst+1; 
                                   if (count_inst==inst_count_to) 
                                   tercnt_inst<=1; 
                    end 
                    else begin 
                  count_inst<=count_inst-1; 
                                                                                                                                                                 if (count_inst==inst_count_to) 
                        tercnt_inst<=1; 
                        end 
                            end 
                                end 
                                   end 
always @(count_inst or inst_up_dn) 
                      if (&count_inst && inst_up_dn) 
                       tercnt_inst <= 1; 
                                else 
                        if (~|count_inst && !inst_up_dn) 
                             tercnt_inst <= 1; 
                                 else 
                                     tercnt_inst <= 0; 

DW03_bictr_dcnto #(width) 
U1 ( .data(inst_data), .count_to(inst_count_to), .inst_up_dn(inst_up_dn), 
.load(inst_load), .cen(inst_cen), .clk(inst_clk), 
.reset(inst_reset), .count(count_inst), .tercnt(tercnt_inst) ); 
endmodule 


I need the test_branch.V and DUT.V 
Thanks a lot! 

Article: 161352
Subject: Re: Up/Down Binary Counter with Dynamic Count-to Flag
From: gnuarm.deletethisbit@gmail.com
Date: Sun, 21 Apr 2019 21:09:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, April 21, 2019 at 6:39:17 PM UTC-4, buse.vic...@decathlon.com wrote:
> hello, i need to solve this problem in verilog:Up/Down Binary Counter with Dynamic Count-to Flag 
>   
> this is start cod: 
> 
> 
> module DW03_bictr_dcnto_inst( inst_data, inst_count_to, inst_up_dn, 
> inst_load, inst_cen, inst_clk, inst_reset, count_inst, tercnt_inst ); 
> parameter width = 8; 
> input [width-1 : 0] inst_data; 
> input [width-1 : 0] inst_count_to; 
> input inst_up_dn; 
> input inst_load; 
> input inst_cen; 
> input inst_clk; 
> input inst_reset; 
> output [width-1 : 0] count_inst; 
> output tercnt_inst; 
> // Instance of DW03_bictr_dcnto 
> DW03_bictr_dcnto #(width) 
> U1 ( .data(inst_data), .count_to(inst_count_to), .up_dn(inst_up_dn), 
> .load(inst_load), .cen(inst_cen), .clk(inst_clk), 
> .reset(inst_reset), .count(count_inst), .tercnt(tercnt_inst) ); 
> endmodule 
> 
> 
> i already have: test.v 
> 
> module DW03_bictr_dcnto_inst( inst_data, inst_count_to, inst_up_dn, 
> inst_load, inst_cen, inst_clk, inst_reset, count_inst, tercnt_inst ); 
> parameter width = 8; 
> input [width-1 : 0] inst_data; 
> input [width-1 : 0] inst_count_to; 
> input inst_up_dn; 
> input inst_load; 
> input inst_cen; 
> input inst_clk; 
> input inst_reset; 
> output [width-1 : 0] count_inst; 
> output tercnt_inst; 
> // Instance of DW03_bictr_dcnto 
> always @(posedge inst_clk or negedge inst_reset) 
>     if (~inst_reset) begin 
>                       count_inst<={width{4'b0000}}; 
>                  end 
>         else begin 
>                  if(~inst_load) begin 
>                                   count_inst<=inst_data; 
>                                 end 
>                      else begin 
>                               if (inst_cen) begin 
>                                 if (inst_up_dn) begin 
>                                   count_inst<=count_inst+1; 
>                                    if (count_inst==inst_count_to) 
>                                    tercnt_inst<=1; 
>                     end 
>                     else begin 
>                   count_inst<=count_inst-1; 
>                                                                                                                                                                  if (count_inst==inst_count_to) 
>                         tercnt_inst<=1; 
>                         end 
>                             end 
>                                 end 
>                                    end 
> always @(count_inst or inst_up_dn) 
>                       if (&count_inst && inst_up_dn) 
>                        tercnt_inst <= 1; 
>                                 else 
>                         if (~|count_inst && !inst_up_dn) 
>                              tercnt_inst <= 1; 
>                                  else 
>                                      tercnt_inst <= 0; 
> 
> DW03_bictr_dcnto #(width) 
> U1 ( .data(inst_data), .count_to(inst_count_to), .inst_up_dn(inst_up_dn), 
> .load(inst_load), .cen(inst_cen), .clk(inst_clk), 
> .reset(inst_reset), .count(count_inst), .tercnt(tercnt_inst) ); 
> endmodule 
> 
> 
> I need the test_branch.V and DUT.V 
> Thanks a lot!

You are welcome.  :) 

-- 

  Rick C.

  - Get a 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

Article: 161353
Subject: FIFO timing, the right way
From: Piotr Wyderski <peter.pan@neverland.mil>
Date: Mon, 22 Apr 2019 08:42:25 +0200
Links: << >>  << T >>  << A >>
Hi all,

I am working on a block that needs to accumulate (at least) K data items 
and then consume them in a burst, while the next group of items might be
flowing in. As the items are not consumed sequentially, a very efficient 
approach is to have a FIFO interface on the write side and a limited 
lookahead random access interface one on the read side. The read side 
works OK. The hard part turned out to be the FIFO full flag setting.
I would like to use the full capacity of the FIFO and stall the data 
writer at the correct moment. Say I want to copy the content of a very 
big ROM into a 4-elements deep FIFO, the basic logic would be as follows:

     writer: process(clock) is begin

         if (rising_edge(clock)) then

             fifo_write_request <= '0';

             if (fifo_full = '0') then

                 fifo_write_request <= '1';
                 rom_address <= rom_address + 1;

             end if;

         end if;

     end process;

In the FIFO interface part I have a 3-bit counter SIZE that calculates 
the number of items in the FIFO. I update it under the same "if 
(rising_edge(clock))" condition to follow the instantaneous 
fifo_write_request & fifo_read_request constellation ("00" => +0, "10" 
=> +1, "01" => -1, "11" => +0).

And here comes the problem: simply setting fifo_full <= (SIZE = 4)
adds a cycle of latency and the writer thinks it is allowed to write one 
more item, corrupting the data. To add insult to injury, SIZE becomes 5
and fifo_full is de-aserted, so the writer pumps in even more data.
Changing it to fifo_full <= (SIZE = 3) behaves equally wrong, just moves
the problem one cycle to the left.

If I move the following into the concurrent part:

   fifo_full <= (SIZE = 4) or ((SIZE = 3) and (fifo_write_request = '1'))

(to account for a possible ongoing write), everything works great, 
because the condition is very logical (no pun intended). But I think
this solution is lame due to its purely combinatorial nature. So, could
you please tell me either:

a) that it is not lame, if it works, it works and and my concerns are 
based on a superstition.

b) or the correct way to setup the flag synchronously.

I don't care if the read side starts as soon as possible (including the 
ongoing write) or one cycle later, so it can be excluded from the 
write-side logic. This is to drive a string of WS2812 LEDs.

	Best regards, Piotr

Article: 161354
Subject: Re: FIFO timing, the right way
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 22 Apr 2019 09:59:53 +0200
Links: << >>  << T >>  << A >>
Hello

On 22/04/2019 08:42, Piotr Wyderski wrote:
[...]
> In the FIFO interface part I have a 3-bit counter SIZE that calculates 
> the number of items in the FIFO. I update it under the same "if 
> (rising_edge(clock))" condition to follow the instantaneous 
> fifo_write_request & fifo_read_request constellation ("00" => +0, "10" 
> => +1, "01" => -1, "11" => +0).
> 
> And here comes the problem: simply setting fifo_full <= (SIZE = 4)
> adds a cycle of latency and the writer thinks it is allowed to write one 
> more item, corrupting the data. To add insult to injury, SIZE becomes 5
> and fifo_full is de-aserted, so the writer pumps in even more data.
> Changing it to fifo_full <= (SIZE = 3) behaves equally wrong, just moves
> the problem one cycle to the left.
> 
> If I move the following into the concurrent part:
> 
>    fifo_full <= (SIZE = 4) or ((SIZE = 3) and (fifo_write_request = '1'))

Either you set the flag at the same time that the counter reaches its 
max value in a sequential process :

fifo_full <= ((SIZE = 3) and (fifo_write_request = '1'));

which has a one cycle latency on the flag test side

Or you do it combinatorially like you did, because sometimes there is no 
other way (and anyway, however you write your logic, it always ends up 
with a bunch of combinatorial stuff followed by a flip-flop)
Instead of comparing SIZE = 4, you could use SIZE > 3 which takes care 
of the case where SIZE goes beyond 4 and is very simple in terms of 
logic because it only needs the most significant bit of SIZE.

BTW, note that in the expression above, fifo_full is of boolean type, 
not std_logic)

Nicolas

Article: 161355
Subject: Re: Up/Down Binary Counter with Dynamic Count-to Flag
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 22 Apr 2019 10:06:29 +0200
Links: << >>  << T >>  << A >>
On 22/04/2019 00:39, buse.victorstefan@decathlon.com wrote:
> hello, i need to solve this problem in verilog:Up/Down Binary Counter with Dynamic Count-to Flag

Ooooh that's a tough one. Your teacher is terribly mean.

No, seriously, do your homework yourself. We'll gladly help but nobody 
here will do it for you.

Nicolas

Article: 161356
Subject: Re: FIFO timing, the right way
From: Piotr Wyderski <peter.pan@neverland.mil>
Date: Mon, 22 Apr 2019 12:29:54 +0200
Links: << >>  << T >>  << A >>
Hi Nicholas,

Nicolas Matringe wrote:

> Either you set the flag at the same time that the counter reaches its 
> max value in a sequential process :
> 
> fifo_full <= ((SIZE = 3) and (fifo_write_request = '1'));
> 
> which has a one cycle latency on the flag test side

It is deceptively simple, but unfortunately it doesn't work.
This is a write-only (no dequeue ops) simulation for a 4-entry FIFO:

https://i.postimg.cc/MHvqvmmt/sim1.png

All values are signals, i.e. the delay is included. It shows two bugs:
5 items have been accepted and no permanent stall is produced.

> Or you do it combinatorially like you did, because sometimes there is no 
> other way (and anyway, however you write your logic, it always ends up 
> with a bunch of combinatorial stuff followed by a flip-flop)

The combinatorial solution works, but for some unknown reason I am not 
particularly fond of it and wanted to consult it with experts here.

> Instead of comparing SIZE = 4, you could use SIZE > 3 which takes care 
> of the case where SIZE goes beyond 4 and is very simple in terms of 
> logic because it only needs the most significant bit of SIZE.

SIZE > 4 means the disaster has already happened.

> BTW, note that in the expression above, fifo_full is of boolean type, 
> not std_logic)

Sure, I just wanted to show the general idea, not to introduce the 
otherwise required strong typing as an extra layer of obfuscation.

	Best regards, Piotr

Article: 161357
Subject: Re: FIFO timing, the right way
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 22 Apr 2019 13:38:06 +0200
Links: << >>  << T >>  << A >>
On 22/04/2019 12:29, Piotr Wyderski wrote:
> Hi Nicholas,
> 
> Nicolas Matringe wrote:
> 
>> Either you set the flag at the same time that the counter reaches its 
>> max value in a sequential process :
>>
>> fifo_full <= ((SIZE = 3) and (fifo_write_request = '1'));
>>
>> which has a one cycle latency on the flag test side
> 
> It is deceptively simple, but unfortunately it doesn't work.
> This is a write-only (no dequeue ops) simulation for a 4-entry FIFO:
> 
> https://i.postimg.cc/MHvqvmmt/sim1.png

You could generate an additional fifo_almost_full signal that is set 
when SIZE reaches 3 and use it like this, along with fifo_full and 
fifo_write_request :

...
   if (fifo_full = 0) and ((fifo_almost_full and fifo_write_request) = 
0) then
     fifo_write_request <= '1';
     rom_address <= rom_address + 1;
   end if;
...


>> Instead of comparing SIZE = 4, you could use SIZE > 3 which takes care 
>> of the case where SIZE goes beyond 4 and is very simple in terms of 
>> logic because it only needs the most significant bit of SIZE.
> 
> SIZE > 4 means the disaster has already happened.

Inded but what about SIZE > 3, as I stated ? It gives you simple 
comparison logic and disaster mitigating (stalling whatever the value is 
once above the limit)

In general when designing these sorts of things I find it helps a huge 
lot to draw the timing waveforms by hand before starting to code.

Nicolas

Article: 161358
Subject: Re: FIFO timing, the right way
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 22 Apr 2019 11:07:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, April 22, 2019 at 2:42:29 AM UTC-4, Piotr Wyderski wrote:
> Hi all,
>=20
> I am working on a block that needs to accumulate (at least) K data items=
=20
> and then consume them in a burst, while the next group of items might be
> flowing in. As the items are not consumed sequentially, a very efficient=
=20
> approach is to have a FIFO interface on the write side and a limited=20
> lookahead random access interface one on the read side. The read side=20
> works OK. The hard part turned out to be the FIFO full flag setting.
> I would like to use the full capacity of the FIFO and stall the data=20
> writer at the correct moment. Say I want to copy the content of a very=20
> big ROM into a 4-elements deep FIFO, the basic logic would be as follows:
>=20
>      writer: process(clock) is begin
>=20
>          if (rising_edge(clock)) then
>=20
>              fifo_write_request <=3D '0';
>=20
>              if (fifo_full =3D '0') then
>=20
>                  fifo_write_request <=3D '1';
>                  rom_address <=3D rom_address + 1;
>=20
>              end if;
>=20
>          end if;
>=20
>      end process;
>=20
> In the FIFO interface part I have a 3-bit counter SIZE that calculates=20
> the number of items in the FIFO. I update it under the same "if=20
> (rising_edge(clock))" condition to follow the instantaneous=20
> fifo_write_request & fifo_read_request constellation ("00" =3D> +0, "10"=
=20
> =3D> +1, "01" =3D> -1, "11" =3D> +0).
>=20
> And here comes the problem: simply setting fifo_full <=3D (SIZE =3D 4)
> adds a cycle of latency and the writer thinks it is allowed to write one=
=20
> more item, corrupting the data. To add insult to injury, SIZE becomes 5
> and fifo_full is de-aserted, so the writer pumps in even more data.
> Changing it to fifo_full <=3D (SIZE =3D 3) behaves equally wrong, just mo=
ves
> the problem one cycle to the left.
>=20
> If I move the following into the concurrent part:
>=20
>    fifo_full <=3D (SIZE =3D 4) or ((SIZE =3D 3) and (fifo_write_request =
=3D '1'))
>=20
> (to account for a possible ongoing write), everything works great,=20
> because the condition is very logical (no pun intended). But I think
> this solution is lame due to its purely combinatorial nature. So, could
> you please tell me either:
>=20
> a) that it is not lame, if it works, it works and and my concerns are=20
> based on a superstition.
>=20
> b) or the correct way to setup the flag synchronously.
>=20
> I don't care if the read side starts as soon as possible (including the=
=20
> ongoing write) or one cycle later, so it can be excluded from the=20
> write-side logic. This is to drive a string of WS2812 LEDs.
>=20
> 	Best regards, Piotr

The usual procedure is to set full and empty inside a clocked process.  I'm=
 assuming that both read and write are clocked by a single clock.  If read =
and write are in different clock domains then you need a dual clock fifo wh=
ich would go beyond the scope of what you're asking for here.

Normally you want FIFO flag outputs to be clocked since that will maximize =
the amount of time available for the external logic that will use those fla=
gs.  If you use 'just logic' to generate the flags then you run the risk of=
 that FIFO flag needlessly becoming part of the critical timing path.  In o=
rder to set the full flag synchronously, you simply set it when there are '=
n-1' things in the FIFO and there is a write request and no read request.  =
VHDL sample code would be:

    if (Reset =3D '1') then
        WrUsedw <=3D 0;
        Full   <=3D '0';
    elsif (Write =3D '1') then
        if (Read =3D '0') then
            if (WrUsedw >=3D FIFO_DEPTH - 1) then
                Full <=3D '1';
            end if;
            WrUsedw <=3D WrUsedw + 1;
        end if;
    elsif (Read =3D '1') then
        Full    <=3D '0';
            WrUsedw  <=3D WrUsedw - 1;
        end if;
    end if;

Kevin Jennings

Article: 161359
Subject: Problem in ADV7611 with Interlace Input
From: Swapnil Patil <swapnilpatil27497@gmail.com>
Date: Wed, 24 Apr 2019 01:44:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello folks,

We are developing demo Aplication for HDMI input and output. for this we are using PicoZed 7030 board with FMC HDMI daughter card.
the daughter card consist of Adv7611 as HDMI receiver and Adv7511 as HDMI transmitter.


when progressive input is given to Adv7611 it detects progressive input and captuers Input resolution of 1920 x 1080p.

register info:
HDMI_INTERLACED , Addr 68 (HDMI), Address 0x0B[5](Read only)
0x0B = 0x22 (detect progressive mode)

Video Input information as follow:

LineWidth =0x780  (1920)
HFrontPorch=0x58
HSyncWidth = 0x2C
HBackPorch = 0x94
HSyncPolarity = 0X01
Field0Height = 0X438  (1080)
Field1Height = 0X438
Field1TotalHeight =0X8CA
Field0TotalHeight =0x8CA
VSyncPolarity =0x01
Field1BackPorch =0x48
Field1SyncWidth =0x0A
Field0FrontPorch =0x08
Field0BackPorch =0x48

while testing with progressive input we observed that we able to see fullscreen output with 1920x1080 resolution.


***************Problem happens when input is chanaged from progressive to interlaced******************************************* 

 when interlace input is given to Adv7611 it detects interlace input and captures Input resolution of 1920 x 540i instead of 1920x1080i.

HDMI_INTERLACED , Addr 68 (HDMI), Address 0x0B[5](Read only)
0x0B = 0x04 (detect interlace mode)
Video Input information as follow:

LineWidth =0x780   (1920)
HFrontPorch=0x58
HSyncWidth = 0x2C
HBackPorch = 0x94
HSyncPolarity = 0X01
Field0Height = 0X21C
Field1Height = 0X21C  (540)
Field0TotalHeight =0X466
Field1TotalHeight =0x466
VSyncPolarity =0x01
Field1BackPorch =0x1F
Field1SyncWidth =0x0A
Field0FrontPorch =0x07
Field0BackPorch =0x1E

so why does this happens? 




Article: 161360
Subject: Re: Problem in ADV7611 with Interlace Input
From: Richard Damon <Richard@Damon-Family.org>
Date: Wed, 24 Apr 2019 07:51:30 -0400
Links: << >>  << T >>  << A >>
On 4/24/19 4:44 AM, Swapnil Patil wrote:
> Hello folks,
> 
> We are developing demo Aplication for HDMI input and output. for this we are using PicoZed 7030 board with FMC HDMI daughter card.
> the daughter card consist of Adv7611 as HDMI receiver and Adv7511 as HDMI transmitter.
> 
> 
> when progressive input is given to Adv7611 it detects progressive input and captuers Input resolution of 1920 x 1080p.
> 
> register info:
> HDMI_INTERLACED , Addr 68 (HDMI), Address 0x0B[5](Read only)
> 0x0B = 0x22 (detect progressive mode)
> 
> Video Input information as follow:
> 
> LineWidth =0x780  (1920)
> HFrontPorch=0x58
> HSyncWidth = 0x2C
> HBackPorch = 0x94
> HSyncPolarity = 0X01
> Field0Height = 0X438  (1080)
> Field1Height = 0X438
> Field1TotalHeight =0X8CA
> Field0TotalHeight =0x8CA
> VSyncPolarity =0x01
> Field1BackPorch =0x48
> Field1SyncWidth =0x0A
> Field0FrontPorch =0x08
> Field0BackPorch =0x48
> 
> while testing with progressive input we observed that we able to see fullscreen output with 1920x1080 resolution.
> 
> 
> ***************Problem happens when input is chanaged from progressive to interlaced******************************************* 
> 
>  when interlace input is given to Adv7611 it detects interlace input and captures Input resolution of 1920 x 540i instead of 1920x1080i.
> 
> HDMI_INTERLACED , Addr 68 (HDMI), Address 0x0B[5](Read only)
> 0x0B = 0x04 (detect interlace mode)
> Video Input information as follow:
> 
> LineWidth =0x780   (1920)
> HFrontPorch=0x58
> HSyncWidth = 0x2C
> HBackPorch = 0x94
> HSyncPolarity = 0X01
> Field0Height = 0X21C
> Field1Height = 0X21C  (540)
> Field0TotalHeight =0X466
> Field1TotalHeight =0x466
> VSyncPolarity =0x01
> Field1BackPorch =0x1F
> Field1SyncWidth =0x0A
> Field0FrontPorch =0x07
> Field0BackPorch =0x1E
> 
> so why does this happens? 
> 
> 
> 

For Interlaced video, the 'Field' Height is 1/2 the Frame Height, so
1920 x 1080i would have a Field0Height and Field1Height of 540.

Progressive video really doesn't have Fields, just frames (The whole
frame is just a single field), so you don't have a Field0 and a Field1.


Article: 161361
Subject: Re: Replaceme EPROM by CPLD/FPGA
From: dahlback@gmail.com
Date: Tue, 7 May 2019 04:40:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
I've done a 27xxx EPROM emulator by simply using a cheap Ebay board with a =
Cyclone IV and some 74HC buffers. The HDL code can be generated simply by u=
sing Octave reading a file and compiling a synthesize-able VHDL file from i=
t's contents. I'm sure it could be possible to create a simple statemachine=
 to fill upp RAM via some UART for dynamic update of contents. Just my 2 ce=
nt.

Article: 161362
Subject: Nallatech BenBlue-II software
From: terafemto@gmail.com
Date: Tue, 28 May 2019 12:02:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello folks,

  I try to use an old FPGA card from Nallatech, it is a BenNuey PCI card.
  I have the FUSE software, but I am missing the CD for the DIME card named BenBlue-II and Nallatech, unfortunately, is not offering support.
  Does anyone know how to find this piece vintage software?

Best regards,
T.

Article: 161363
Subject: bare-metal ZYNQ
From: John Larkin <jjlarkin@highland_snip_technology.com>
Date: Wed, 12 Jun 2019 16:32:35 -0700
Links: << >>  << T >>  << A >>


Assume I'm a pointy-haired boss trying to help one of my guys.

I think that...

The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
figures out what the boot device is (serial flash, SD card, whatever)
and reads in a secondary boot program, which the Xilinx tools provide
as part of a build. That loader then reads the entire FPGA config
bitstream into DRAM, and sets up a giant DMA transfer to configure the
FPGA. That's all standard in the tools.

But what if there's no DRAM? My guy thinks he will have to write his
own ARM application, which is booted at load time, and inside that
would be a routine to read from the boot media and configure the FPGA
in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
figures he could do that in a few days.

Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
Does the tool chain support that (people here think not) or is there
some loader already coded somewhere?

(Our support, through a distributor, isn't very good.)

Thanks





-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 161364
Subject: Re: bare-metal ZYNQ
From: Gerhard Hoffmann <dk4xp@arcor.de>
Date: Thu, 13 Jun 2019 02:07:55 +0200
Links: << >>  << T >>  << A >>
Am 13.06.19 um 01:32 schrieb John Larkin:
> 
> 
> Assume I'm a pointy-haired boss trying to help one of my guys.
> 
> I think that...
> 
> The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
> figures out what the boot device is (serial flash, SD card, whatever)
> and reads in a secondary boot program, which the Xilinx tools provide
> as part of a build. That loader then reads the entire FPGA config
> bitstream into DRAM, and sets up a giant DMA transfer to configure the
> FPGA. That's all standard in the tools.
> 
> But what if there's no DRAM? My guy thinks he will have to write his
> own ARM application, which is booted at load time, and inside that
> would be a routine to read from the boot media and configure the FPGA
> in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
> figures he could do that in a few days.
> 
> Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
> Does the tool chain support that (people here think not) or is there
> some loader already coded somewhere?

A Zynq without RAM is like a car without tyres.

Maybe you can peek in the sources for the Red Pitaya; it is also
based on a Zynq and there are a number of Linuxes available
for it. I have one, but have avoided digging that deep.

If the loading interface is only remotely similar to other
Xilinx FPGAs, it should be easy to replace the one large DMA
xfer by many small ones.

regards, Gerhard



Article: 161365
Subject: Re: bare-metal ZYNQ
From: John Larkin <jjlarkin@highland_snip_technology.com>
Date: Wed, 12 Jun 2019 17:35:04 -0700
Links: << >>  << T >>  << A >>
On Thu, 13 Jun 2019 02:07:55 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
wrote:

>Am 13.06.19 um 01:32 schrieb John Larkin:
>> 
>> 
>> Assume I'm a pointy-haired boss trying to help one of my guys.
>> 
>> I think that...
>> 
>> The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
>> figures out what the boot device is (serial flash, SD card, whatever)
>> and reads in a secondary boot program, which the Xilinx tools provide
>> as part of a build. That loader then reads the entire FPGA config
>> bitstream into DRAM, and sets up a giant DMA transfer to configure the
>> FPGA. That's all standard in the tools.
>> 
>> But what if there's no DRAM? My guy thinks he will have to write his
>> own ARM application, which is booted at load time, and inside that
>> would be a routine to read from the boot media and configure the FPGA
>> in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
>> figures he could do that in a few days.
>> 
>> Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
>> Does the tool chain support that (people here think not) or is there
>> some loader already coded somewhere?
>
>A Zynq without RAM is like a car without tyres.

There's enough of sram internal to the chip for many applications.

>
>Maybe you can peek in the sources for the Red Pitaya; it is also
>based on a Zynq and there are a number of Linuxes available
>for it. I have one, but have avoided digging that deep.
>
>If the loading interface is only remotely similar to other
>Xilinx FPGAs, it should be easy to replace the one large DMA
>xfer by many small ones.

Yes, but I was thinking that someone has already done the work.


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 161366
Subject: Re: bare-metal ZYNQ
From: Jan Panteltje <pNaOnStPeAlMtje@yahoo.com>
Date: Thu, 13 Jun 2019 06:14:09 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Wed, 12 Jun 2019 16:32:35 -0700) it happened John Larkin
<jjlarkin@highland_snip_technology.com> wrote in
<qm13gel4ifba24lb4p8gdeeusufc2b433b@4ax.com>:

>But what if there's no DRAM?


That thing runs Linux?
Does not Linux use the DRAM?


If not using Linux and DRAM then a simpler cheaper FPGA board?


Article: 161367
Subject: Re: bare-metal ZYNQ
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 13 Jun 2019 08:06:05 +0100
Links: << >>  << T >>  << A >>
On 13/06/19 01:35, John Larkin wrote:
> On Thu, 13 Jun 2019 02:07:55 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
> wrote:
> 
>> Am 13.06.19 um 01:32 schrieb John Larkin:
>>>
>>>
>>> Assume I'm a pointy-haired boss trying to help one of my guys.
>>>
>>> I think that...
>>>
>>> The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
>>> figures out what the boot device is (serial flash, SD card, whatever)
>>> and reads in a secondary boot program, which the Xilinx tools provide
>>> as part of a build. That loader then reads the entire FPGA config
>>> bitstream into DRAM, and sets up a giant DMA transfer to configure the
>>> FPGA. That's all standard in the tools.
>>>
>>> But what if there's no DRAM? My guy thinks he will have to write his
>>> own ARM application, which is booted at load time, and inside that
>>> would be a routine to read from the boot media and configure the FPGA
>>> in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
>>> figures he could do that in a few days.
>>>
>>> Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
>>> Does the tool chain support that (people here think not) or is there
>>> some loader already coded somewhere?
>>
>> A Zynq without RAM is like a car without tyres.
> 
> There's enough of sram internal to the chip for many applications.

For small software applications, it might be worth
considering using the same FPGA fabric (Artix 7 or
Kintex 7) and using a softcore processor.

That would sidestep those problems, might be cheaper,
and would bring its own, hopefully lesser, problems.

Article: 161368
Subject: Re: bare-metal ZYNQ
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 13 Jun 2019 07:45:37 -0500
Links: << >>  << T >>  << A >>
On Wed, 12 Jun 2019 16:32:35 -0700, John Larkin wrote:

> Assume I'm a pointy-haired boss trying to help one of my guys.
> 
> I think that...
> 
> The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It figures
> out what the boot device is (serial flash, SD card, whatever) and reads
> in a secondary boot program, which the Xilinx tools provide as part of a
> build. That loader then reads the entire FPGA config bitstream into
> DRAM, and sets up a giant DMA transfer to configure the FPGA. That's all
> standard in the tools.
> 
> But what if there's no DRAM? My guy thinks he will have to write his own
> ARM application, which is booted at load time, and inside that would be
> a routine to read from the boot media and configure the FPGA in chunks,
> using a small uP RAM buffer, maybe DMA or maybe not. He figures he could
> do that in a few days.
> 
> Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
> Does the tool chain support that (people here think not) or is there
> some loader already coded somewhere?
> 
> (Our support, through a distributor, isn't very good.)
> 
> Thanks

Our Zynq 7 boards have DRAM (natch) but we choose to load the PL (FPGA 
fabric) after boot rather than as part of the FSBL.

What you want to do is possible, but you won't get much support from 
Xilinx.  You will also lose some of the built-in security features.
Considering the costs of DRAM (plus the extra PCB layers you will need) 
you might be better off putting it on the board.  I'm assuming you don't 
have really large volumes, of course.

Allan

Article: 161369
Subject: Re: bare-metal ZYNQ
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Thu, 13 Jun 2019 08:04:31 -0700
Links: << >>  << T >>  << A >>
On Thu, 13 Jun 2019 08:06:05 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 13/06/19 01:35, John Larkin wrote:
>> On Thu, 13 Jun 2019 02:07:55 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
>> wrote:
>> 
>>> Am 13.06.19 um 01:32 schrieb John Larkin:
>>>>
>>>>
>>>> Assume I'm a pointy-haired boss trying to help one of my guys.
>>>>
>>>> I think that...
>>>>
>>>> The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
>>>> figures out what the boot device is (serial flash, SD card, whatever)
>>>> and reads in a secondary boot program, which the Xilinx tools provide
>>>> as part of a build. That loader then reads the entire FPGA config
>>>> bitstream into DRAM, and sets up a giant DMA transfer to configure the
>>>> FPGA. That's all standard in the tools.
>>>>
>>>> But what if there's no DRAM? My guy thinks he will have to write his
>>>> own ARM application, which is booted at load time, and inside that
>>>> would be a routine to read from the boot media and configure the FPGA
>>>> in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
>>>> figures he could do that in a few days.
>>>>
>>>> Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
>>>> Does the tool chain support that (people here think not) or is there
>>>> some loader already coded somewhere?
>>>
>>> A Zynq without RAM is like a car without tyres.
>> 
>> There's enough of sram internal to the chip for many applications.
>
>For small software applications, it might be worth
>considering using the same FPGA fabric (Artix 7 or
>Kintex 7) and using a softcore processor.
>
>That would sidestep those problems, might be cheaper,
>and would bring its own, hopefully lesser, problems.

That has been suggested. There are downsides:

New tool chain

Slower CPU, but that seldom matters here

Uses valuable FPGA resources, especially RAM

Floating point would use more

The Zynq ARM comes with all sorts of hard goodies, FP, counter/timers,
SPI, UARTS, DMA, I2C, like that, all built.


The downside of the ZYNQ is that some balls are dedicated to uP and
some to FPGA. Pity they didn't allow dual use on them.




-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 161370
Subject: Re: bare-metal ZYNQ
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Thu, 13 Jun 2019 08:09:16 -0700
Links: << >>  << T >>  << A >>
On Thu, 13 Jun 2019 06:14:09 GMT, Jan Panteltje
<pNaOnStPeAlMtje@yahoo.com> wrote:

>On a sunny day (Wed, 12 Jun 2019 16:32:35 -0700) it happened John Larkin
><jjlarkin@highland_snip_technology.com> wrote in
><qm13gel4ifba24lb4p8gdeeusufc2b433b@4ax.com>:
>
>>But what if there's no DRAM?
>
>
>That thing runs Linux?
>Does not Linux use the DRAM?
>
>
>If not using Linux and DRAM then a simpler cheaper FPGA board?

I said "bare metal."

Separate FPGA and CPU chips is an option that we use a lot already,
but it needs a chip-chip parallel interface that uses a lot of balls,
or a slow SPI link.

The NXP uP that we usually use for this combo, LPC3250, looks to be
EOL, so we're looking for a next-generation product platform. 


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 161371
Subject: Re: bare-metal ZYNQ
From: David Brown <david.brown@hesbynett.no>
Date: Thu, 13 Jun 2019 17:31:49 +0200
Links: << >>  << T >>  << A >>
On 13/06/2019 17:09, John Larkin wrote:
> On Thu, 13 Jun 2019 06:14:09 GMT, Jan Panteltje
> <pNaOnStPeAlMtje@yahoo.com> wrote:
> 
>> On a sunny day (Wed, 12 Jun 2019 16:32:35 -0700) it happened John Larkin
>> <jjlarkin@highland_snip_technology.com> wrote in
>> <qm13gel4ifba24lb4p8gdeeusufc2b433b@4ax.com>:
>>
>>> But what if there's no DRAM?
>>
>>
>> That thing runs Linux?
>> Does not Linux use the DRAM?
>>
>>
>> If not using Linux and DRAM then a simpler cheaper FPGA board?
> 
> I said "bare metal."
> 
> Separate FPGA and CPU chips is an option that we use a lot already,
> but it needs a chip-chip parallel interface that uses a lot of balls,
> or a slow SPI link.
> 
> The NXP uP that we usually use for this combo, LPC3250, looks to be
> EOL, so we're looking for a next-generation product platform. 
> 

Consider NXP's i.mx RT family.  They have Cortex-M7 cpus at about 600
MHz, and have quad SPI or octal SPI links.  These are typically for
flash for booting, but you could use one link for the flash and one for
a high speed interface to the FPGA.


Article: 161372
Subject: Re: bare-metal ZYNQ
From: Michael Kellett <mk@mkesc.co.uk>
Date: Thu, 13 Jun 2019 16:42:20 +0100
Links: << >>  << T >>  << A >>
On 13/06/2019 16:09, John Larkin wrote:
> On Thu, 13 Jun 2019 06:14:09 GMT, Jan Panteltje
> <pNaOnStPeAlMtje@yahoo.com> wrote:
> 
>> On a sunny day (Wed, 12 Jun 2019 16:32:35 -0700) it happened John Larkin
>> <jjlarkin@highland_snip_technology.com> wrote in
>> <qm13gel4ifba24lb4p8gdeeusufc2b433b@4ax.com>:
>>
>>> But what if there's no DRAM?
>>
>>
>> That thing runs Linux?
>> Does not Linux use the DRAM?
>>
>>
>> If not using Linux and DRAM then a simpler cheaper FPGA board?
> 
> I said "bare metal."
> 
> Separate FPGA and CPU chips is an option that we use a lot already,
> but it needs a chip-chip parallel interface that uses a lot of balls,
> or a slow SPI link.
> 
> The NXP uP that we usually use for this combo, LPC3250, looks to be
> EOL, so we're looking for a next-generation product platform.
> 
> 
May not be relevant right now but you could look at the ST M-7s as a 
step beyond the NXP part.
STM32H7...  400Mhz, lots of RAM and flash on chip 64 bit FPU, and multi 
bit SPI ("dual quad SPI" in ST speak) which would ease that uP<->FPGA 
bottleneck a bit. They claim max 133 MHz clock on it so with 8 bit data 
that's quite quick. The downside is that the FPGA will need to pretend 
it's a flash memory but that may not be too hard.

MK




---
This email has been checked for viruses by AVG.
https://www.avg.com


Article: 161373
Subject: Re: bare-metal ZYNQ
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Thu, 13 Jun 2019 09:34:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, June 12, 2019 at 7:34:09 PM UTC-4, John Larkin wrote:
> Assume I'm a pointy-haired boss trying to help one of my guys.
> 
> I think that...
> 
> The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
> figures out what the boot device is (serial flash, SD card, whatever)
> and reads in a secondary boot program, which the Xilinx tools provide
> as part of a build. That loader then reads the entire FPGA config
> bitstream into DRAM, and sets up a giant DMA transfer to configure the
> FPGA. That's all standard in the tools.
> 
> But what if there's no DRAM? My guy thinks he will have to write his
> own ARM application, which is booted at load time, and inside that
> would be a routine to read from the boot media and configure the FPGA
> in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
> figures he could do that in a few days.
> 
> Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
> Does the tool chain support that (people here think not) or is there
> some loader already coded somewhere?
> 
> (Our support, through a distributor, isn't very good.)
> 
> Thanks
> 
> 
> 
> 
> 
> -- 
> 
> John Larkin         Highland Technology, Inc
> picosecond timing   precision measurement 
> 
> jlarkin att highlandtechnology dott com
> http://www.highlandtechnology.com

You're in the Bay Area, right?  I've had good experiences with the Avnet Xilinx FAEs out there.  I can put you in touch with some folks if you need.

There is a reference design for running out of On-Chip Memory (OCM):
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842377/Zynq-7000+AP+SoC+Boot+-+Booting+and+Running+Without+External+Memory+Tech+Tip

It's worth reviewing UG585 - Zynq-7000 SoC TRM, Chapter 6: Boot and Configuration as well.  Section 6.4 - Device Boot and PL Configuration is particularly helpful here.
https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

In a lot of cases, the PL is configured by the FSBL, which can be run from OCM and it's rather trivial to enable that in the Xilinx SDK.  

Article: 161374
Subject: Re: bare-metal ZYNQ
From: Jan Panteltje <pNaOnStPeAlMtje@yahoo.com>
Date: Thu, 13 Jun 2019 17:35:33 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Thu, 13 Jun 2019 08:09:16 -0700) it happened John Larkin
<jjlarkin@highlandtechnology.com> wrote in
<agp4getd0ualcf8f9sl2s5ug2541t03e7g@4ax.com>:

>On Thu, 13 Jun 2019 06:14:09 GMT, Jan Panteltje
><pNaOnStPeAlMtje@yahoo.com> wrote:
>
>>On a sunny day (Wed, 12 Jun 2019 16:32:35 -0700) it happened John Larkin
>><jjlarkin@highland_snip_technology.com> wrote in
>><qm13gel4ifba24lb4p8gdeeusufc2b433b@4ax.com>:
>>
>>>But what if there's no DRAM?
>>
>>
>>That thing runs Linux?
>>Does not Linux use the DRAM?
>>
>>
>>If not using Linux and DRAM then a simpler cheaper FPGA board?
>
>I said "bare metal."
>
>Separate FPGA and CPU chips is an option that we use a lot already,
>but it needs a chip-chip parallel interface that uses a lot of balls,
>or a slow SPI link.
>
>The NXP uP that we usually use for this combo, LPC3250, looks to be
>EOL, so we're looking for a next-generation product platform. 

OK, just did a read of the 80 pages datasheet of the LPC3250.
While reading I was thinking about the chip in the Raspberry pi
 Broadcom BCM2835 -- 2837
but that has no ADC.. but does have HDMI out..
There exists a FPGA plugin board for the Raspberry.

It is a pity that so many things go EOL in a short time,
OTOH it is a throw away society.
And very strong competition does kill some products.

It all depends on what you want to do.

A Raspberry plus some external ADC 35$ + ??
VERY powerful platform, really, GCC compiler, Linux, lots of I/O.
USB, Ethernet, HDMI, analog video out, analog audio out, 
GPIO for extra boards... SDcard, camera interface, logic level serial, PWM,
PLL frequency generators, and although every year a new model, the  
basics stay more or less the same, quadcore now, lots of DRAM,
availability...

Depends on what you call 'bare metal' these days.
 https://en.wikipedia.org/wiki/Raspberry_Pi

I have several in use...

It is sort of moving to an ever higher level of integration.



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