OpenCores

OpenCores

no use

no use

1/1

no use

no use

uart16550 by Unknown on Jan 9, 2004			Not available!
Hi all, I was messing around with the UART 16550, and the process of not getting it to work how I wanted, I was perusing the source... I noticed that all the registers are defined thusly: always @(posedge clk or posedge wb_rst_i) if (wb_rst_i) lsr0_d <= #1 0; else lsr0_d <= #1 lsr0; Now, I'm not a verilog guy, but to my limited understanding that infers a register with an async reset, which is not what wishbone calls for... or have I missed something? Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt Stratford Road, Solihull, B90 4GW. UK Tel: +44 (0)121-627-3569 - <A HREF="http://www.opencores.org/mailman/listinfo/cores">martin.j.thompson at trw.com</A> Hi all, I was messing around with the UART 16550, and the process of not getting it to work how I wanted, I was perusing the source... I noticed that all the registers are defined thusly: always @(posedge clk or posedge wb_rst_i) if (wb_rst_i) lsr0_d martin.j.thompson at trw.com

uart16550 by Unknown on Jan 9, 2004			Not available!
The wishbone spec says that the reset signal should be synchronous to the clock. I am moving into another holy war area now, but ... asynchronous resets do have some advantages over synchronous resets. My personal preference is a reset that's asserted asynchronously (so that reset is applied, even if there's no clock), and negated synchronously. Asserting the reset would be in violation with the wishbone spec. But as everything is (should be) reset that doesn't matter so much. Much more important is the fact that the reset is released in a synchronous matter. Richard [q] -----Original Message----- From: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores-bounces at opencores.org</A>][/q] On [q] Behalf Of Martin.J Thompson Sent: Friday, January 09, 2004 4:15 PM To: <A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A> Subject: [oc] uart16550 Hi all, I was messing around with the UART 16550, and the process of not[/q] getting [q] it to work how I wanted, I was perusing the source... I noticed that[/q] all [q] the registers are defined thusly: always @(posedge clk or posedge wb_rst_i) if (wb_rst_i) lsr0_d <= #1 0; else lsr0_d <= #1 lsr0; Now, I'm not a verilog guy, but to my limited understanding that[/q] infers a [q] register with an async reset, which is not what wishbone calls for...[/q] or [q] have I missed something? Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt Stratford Road, Solihull, B90 4GW. UK Tel: +44 (0)121-627-3569 - <A HREF="http://www.opencores.org/mailman/listinfo/cores">martin.j.thompson at trw.com</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/cores">http://www.opencores.org/mailman/listinfo/cores</A>[/q] The wishbone spec says that the reset signal should be synchronous to the clock. I am moving into another holy war area now, but ... asynchronous resets do have some advantages over synchronous resets. My personal preference is a reset that's asserted asynchronously (so that reset is applied, even if there's no clock), and negated synchronously. Asserting the reset would be in violation with the wishbone spec. But as everything is (should be) reset that doesn't matter so much. Much more important is the fact that the reset is released in a synchronous matter. Richard -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Martin.J Thompson Sent: Friday, January 09, 2004 4:15 PM To: cores at opencores.org Subject: [oc] uart16550 Hi all, I was messing around with the UART 16550, and the process of not getting it to work how I wanted, I was perusing the source... I noticed that all the registers are defined thusly: always @(posedge clk or posedge wb_rst_i) if (wb_rst_i) lsr0_d else lsr0_d Now, I'm not a verilog guy, but to my limited understanding that infers a register with an async reset, which is not what wishbone calls for... or have I missed something? Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt Stratford Road, Solihull, B90 4GW. UK Tel: +44 (0)121-627-3569 - martin.j.thompson at trw.com _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

uart16550 by Unknown on Jan 9, 2004			Not available!
[q] I am moving into another holy war area now, but ... asynchronous resets do have some advantages over synchronous resets. My personal preference is a reset that's asserted asynchronously (so that reset is applied, even if there's no clock), and negated synchronously. Richard[/q] I beleive that the holly war was ended and you're solution was the one which win. But at synopsys some guy's said that for deep submicron (<0.13 Âµm) some designer are affraid of glitch or SEU on the udge reset line that could cause metastability inside the chip. So let's start the new holy ware :) nicO I am moving into another holy war area now, but ... asynchronous resets do have some advantages over synchronous resets. My personal preference is a reset that's asserted asynchronously (so that reset is applied, even if there's no clock), and negated synchronously. Richard I beleive that the holly war was ended and you're solution was the one which win. But at synopsys some guy's said that for deep submicron (designer are affraid of glitch or SEU on the udge reset line that could cause metastability inside the chip. So let's start the new holy ware :) nicO

no use

no use

1/1

no use

no use

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.