Jump to content

foster911

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    1
  1. foster911

    synthesizeable systemc code

    All CatapultC's related FAQs here: http://communities.mentor.com/mgcx/community/asic_fpga/esl
  2. foster911

    Verification Methodologies for SystemC

    This is also another methodology. Simply register and download the source codes. Teal & Truss: http://www.trusster.com/products/teal/ http://www.trusster.com/products/truss/ There is a book named "Hardware Verification with C++" describing the above libraries. I have not put them in practice yet. If someone has any knowledge about them, could light me up please. Do they yield more facilities than SCV. How about AVM?
  3. This is AVM (Advanced Verification Methodology) from Mentor Graphics. This is the only MMM... for SystemC. Could someone please tell that this library is still supported by mentor or not? AVM_3-2 (Cook Book is also included): http://depositfiles.com/files/0k2qh7eni
  4. Dynamic Assertion-Based Verification for SystemC by Deian Tabakov http://www.cs.rice.edu/CS/Verification/Theses/Archive/dtabakov_dissertation2010.pdf Question: Is it possible to do Assertion-Based Verification with pure SystemC and available SCV in reality like the SystemVerilog Assertion does or it needs changing the Kernel or extending the SCV API? How about UVM in SystemC? This could have the advantage of getting rid of language changing.
  5. Some tools do this job for you automatically (like Mentor Vista). In fact your question needs comprehensive answer. I mean you're actually asking the philosophy of emerging and existence of TLM. Short answers to this question just would confound you. You may never find the answer of this question completely just by reading papers (even from IEEE) or looking at the samples due to the complexity of the matter. I suggest you to find a "ground up" book for this question like the one that pre-exists for the SystemC named " SystemC from the Ground Up". I suggest the book mentioned previously at below post. This is the only book available in the web related to TLM: http://forums.accellera.org/topic/1389-use-cases-of-tlm-over-systemc/#entry5784 The other book is "TLM 2.0: From the Ground Up http://www.springer.com/engineering/circuits+%26+systems/book/978-1-4419-8791-4" that is expected to be available for public access in January 29, 2015 (if I am wrong please someone corrects me). You could also look at: http://www.embecosm.com/resources/appnotes/ http://www.accellera.org/downloads/standards/ocp/adm.zip may also help. It's based on OCP.
  6. @amitk3553 I have problem sending pm to you. Please give me an email. This book talks about OSCI TLM and OCP TL(recently acquired by Accellera): Accellera Acquires OCP 3.0 Standard http://forums.accellera.org/topic/1518-accellera-acquires-ocp-30-standard/ There is also a book named "Introduction to Open Core Protocol (OCP)" that would be useful too.
  7. Please read: http://forums.accellera.org/topic/1389-use-cases-of-tlm-over-systemc/#entry5784 Please look at the TOC of the book. The whole book answers all of these kinds of questions completely and opens new doors to the TLM 2.0 paradigm. The chapters are not independent and follow previous ones that at the end you could have an allegation of having moderate knowledge about TLM 2.0.
  8. @ mitk3553 As every SystemC user know, modeling in TLM2 is the most complicated job for the developers and because of misunderstanding the TLM concept, it seems that TLM2 would be undiscoverable. I believe that most aspects of modeling and verification tasks are for software designers not hardware ones. TLM2 is one of those aspects and the reason why hardware designers with verilog background have always trouble with that is this. STARC Transaction-Level Modeling (TLM) Guide is the best reference for TLM2 in the web and will answer all of your questions. This is only first 50 pages of the book: http://depositfiles.com/files/p3jb7k0b7 The whole book is 283 pages.
  9. foster911

    ParC = Parallel C++

    extensions to C++ for lightweight multithreading in a way similar to that found in HDLs (e.g. Verilog and VHDL). The extended language should be a replacement for most HDLs and SystemC as well as being usable for programming many-core and distributed parallel systems. ParC is being developed as part of the V2000 open-source simulator project. ......................... Motivation Problems with existing MT/parallel approaches Having worked on a few SMP parallel processing projects using pThreads and Quickthreads with C/C++, it became obvious fairly quickly that there are a number of problems with the approach: Very hard to debug with more than a few threads running Very expensive in CPU with a lot of threads due to the context switch overhead Very hard to statically analyze or formally verify because of the dynamic nature of C/C++ code The reason that people use pThreads is (of course) historic, the general method of extension in C is to add functionality through external libraries, so pThreads is just a layer over the operating system's own internal multi-threading/process management that is also used for more general (heavy-weight) process management. The fundamental flaw in the approach is that the pThreads libraries take a routine as the thread entry point, create a new stack frame and then call the routine on the new stack, this causes threads to have a large memory footprint and often odd bugs due to the stack being of limited depth. Multi-Threaded Languages There are a couple of well known multi-threaded programming languages: Verilog and VHDL. These are better known as hardware description languages (HDLs). Hardware descriptions are different from normal coding in that the description is intrinsically parallel (with a large number of threads) and entirely static. Both Verilog and VHDL have their roots back in the 1980s and have semantic description problems that are tied to assumptions made at that time: No power management (as required in most modern designs) Limited back-annotation (feedback of manufacturing effects) Analog was an afterthought (so not well integrated) Limited availability and lack of native compile (no equivalent of GCC for full language) Limited support for RF/Wireless modeling ESL Language - The "Holy Grail" ? Electronic Systems Level (ESL) methodology wants to look at the design process for systems from software down to Silicon in a wholistic way. To do this cleanly requires a single language that is usable as a programming language and also as an HDL. Most ESL designers work with SystemC (a C++ HDL class library) which suffers from the problems mentioned in the first paragraph above. An attempt was made to merge C and Verilog in the language SuperLog which later morphed into rev 1 of SystemVerilog. Unfortunately rev 2 went in other directions, so SystemVerilog is not really usable as an ESL language. ParC ParC came out of the observation that the evolution of HDLs was simply the addition of features from programming languages (like C and Java). In order to create a usable ESL language (as in: liked by programmers), it would be necessary to added the features of an HDL to an existing programming language. C++ is the prime candidate for this because of symmetries between the "class" syntax/semantics and modules/tasks in Verilog/VHDL. ParC is therefore intended to be a functional superset of Verilog and VHDL (for at least the parts used for actual hardware description). The new constructs being added to C++ are clean implementations of the abstractions needed for hardware description and synthesis. ................. Homepage: http://parallel.cc/cgi-bin/bfx.cgi/index1.html
  10. The complexity of modern embedded systems, which are increasingly based on heterogeneous MultiProcessor-SoC (MP-SoC) architectures, has led to the emergence of system-level design. To cope with this design complexity, system-level design aims at raising the abstraction level of the design process. Key enablers to this end are, for example, the use of architectural platforms to facilitate re-use of IP components and the notion of high-level system modeling and simulation. The latter allows for capturing the behavior of platform components and their interactions at a high level of abstraction. As such, these high-level models minimize the modeling effort and are optimized for execution speed, and can therefore be applied during the very early design stages to perform, for example, architectural Design Space Exploration (DSE). Such early DSE is of paramount importance as early design choices heavily influence the success or failure of the final product. System-level design for MP-SoC based embedded systems typically involves a number of challenging tasks. For example, applications need to be decomposed into parallel specifications so that they can be mapped onto an MP-SoC architecture. Subsequently, applications need to be partitioned into HW and SW parts since MP-SoC architectures often are heterogeneous in nature. To this end, MP-SoC platform architectures need to be modeled and simulated to study system behavior and to evaluate a variety of different design options. Once a good candidate architecture has been found, it needs to be synthesized, which involves the synthesis of its architectural components as well as the mapping of applications onto the architecture. To accomplish all of these tasks, a range of different tools and tool-flows is often needed, potentially leaving designers with all kinds of interoperability problems. Moreover, there typically remains a large gap between the deployed system-level models and actual implementations of the system under study, known as the implementation gap. Currently, there exist no mature methodologies, techniques, and tools to effectively and efficiently convert system-level system specifications to RTL specifications. The Daedalus framework addresses these system-level design challenges. Its main objective is to bridge the aforementioned implementation gap for the design of multimedia MP-SoCs. It does so by providing an integrated and highly-automated environment for system-level architectural exploration, system-level synthesis, programming and prototyping. http://daedalus.liacs.nl/ http://daedalus.liacs.nl/download.html
  11. foster911

    systemC vcd trace file cannot open display

    As everyone know, being able to view VCD files inside the verification platforms like Mentor QuestaSim (or ModelSim) or Aldec Riviera needs below commands respectively: vcd2wlf vcd2asdb Then by simply dragging the generated *.wlf and *.asdb files inside the tools, traced objects can be viewed in the waveform window. I did the above procedures for your VCD file and was able to view them without any error inside both tools. I suggest you also do that instead of trying to use gtkwave.
  12. Sorry for duplication! Any way to remove this? Thanks!
  13. ArchC is a powerful and modern open-source architecture description language designed at University of Campinas by the ArchC team in the Computer Systems Laboratory, Institute of Computing. Our goal in designing ArchC is to provide architecture designers with a tool that allows them to rapidly evaluate new ideas in areas such as: processor and ISA design, memory hierarchy, and other aspects of computer architecture research. Fast prototyping Easy to use language, describes hardware and processor using high level hardware abstractions. ISA simulator ArchC generates compiled and interpreted simulators based on a machine models. SystemC technology ArchC is based on SystemC, a hardware description language that receives a strong support from many companies in the computer industry. Automatic toolchain generation Generates binutils-based assemblers and linkers, C and C++ Clang-based frontend and LLVM Backends for new models. Download Link: http://www.archc.org/
  14. foster911

    systemC synthesis guidlines

    There are 2 tedious tasks in the field of ESL and SOC: 1- Microprocessor model creation and Compiler and Driver development 2- Hardware/Software partitioning and interfacing them together. For the second part, please read below DOC. It's not related to SystemC but can reveal lots of ambiguities. Hardware(Verilog or VHDL)/Software(C or assembly)/Micro-processor tuning and mixing http://depositfiles.com/files/grlag48ee
  15. foster911

    data structure with link list

    Most synthesis tools recommend fixed size arrays.
×