Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
=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
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
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
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
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: 161355On 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. NicolasArticle: 161356
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, PiotrArticle: 161357
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
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: 161359Hello 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
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
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
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
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.comArticle: 161364
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, GerhardArticle: 161365
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.comArticle: 161366
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
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
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. AllanArticle: 161369
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 electronicsArticle: 161370
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 electronicsArticle: 161371
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
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: 161373On 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
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:
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